output.csv

|Link|Heading|Abstract|Claims
0|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=13&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|User-configurable network performance monitors|A network analysis system provides for a user-definable display of information related to messages communicated on the network. The network analysis system includes one or more display formats that provide a display of message exchanges between nodes of a network, and a display augmenter that provides additional information on the display based on a user-defined visualization. The user defined visualization includes augmenting the display based on user-defined coloring characteristics and/or augmenting the display with user-defined labels. To further facilitate user control of the augmentation of the display, the system accepts user-defined programs for discriminating among messages, for controlling the labeling of messages, and for controlling the coloring of messages and labels. Commonly used user-defined characteristics and labels are stored in a library, for use via a selection from among the library entries.|
1|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=6&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|System and method for facilitating static analysis of software applications|In system for enabling static vulnerability analysis of a software/web application that includes an indirectly modeled language portion and a directly modeled language portion, an indirectly modeled language information extractor select nodes of certain types from a syntax tree corresponding to the indirectly modeled language source code. Generally, the types of nodes that are selected are relevant to taint propagation. For one or more of the selected nodes, one or more statements corresponding to one or more of a type of the node, an input to the node, and an object associated with the node are generated. A static analyzer configured for a directly modeled language may perform vulnerability analysis of the software/web application using the generated statements.|
2|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=26&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|System and method for invoking functionalities using contextual relations|A method for obtaining contextually related instances. The method comprises providing a map of a plurality of contextual relations between a plurality of instance types and a plurality of functionalities. Each one of the functionalities is associated with one of the mapped contextual relations and configured for providing one or more instances of a respective type. The method further comprises receiving a contextual linkage between a known instance and a requested instance, identifying a match between the contextual linkage and a segment of the map, and obtaining the requested instance by using the known instance along with a group of which is selected from the functionalities; each member of the group is associated with a contextual relation in the segment.|"1. A method for obtaining contextually related instances using one or more different functionality modules, comprising: a) providing to a system comprising at least oneserver a plurality of different functionality modules and a graph mapping a plurality of contextual relations among a plurality of instance types, each said functionality module being associated with at least one of said plurality of contextual relationsin said graph and configured for providing at least one instance of a respective type; b) receiving a query defining contextual linkage between at least one known instance and at least one requested instance from a client connected to said system via anetwork, said at least one known instance is not directly associated with a type of said requested instance; c) identifying, by said system, a match between said contextual linkage and a sub-graph of said graph, said sub-graph being associated with agroup of said plurality of functionality modules; and d) dividing said query to a number of single step queries; e) iteratively executing at least some of said number of single step queries by said system, wherein one of said number of single stepqueries includes a first member of said group with said at least one known instance for obtaining at least one intermediate instance and another of said number of single step queries includes a second member of said group with said at least oneintermediate instance for obtaining said at least one requested instance; f) responding to said received query with said obtained at least one requested Instance; wherein said functionality module implements at least one of a web service and a codescript; wherein members of said group are executed in an order matching dependencies in said sub graph. 2. The method of claim 1, wherein said receiving comprises receiving a search query comprising said contextual linkage. 3. The method of claim 1, further comprises converting said contextual linkage to an additional graph before said matching. 4. The method of claim 3, wherein said sub-graph is an ordered graph comprising a plurality of sub-graphs, said obtaining comprises executing each member of said group according to the order in said ordered graph. 5. The method of claim 1, wherein said at least one known instance appears in a document, further comprising selecting said contextual linkage according to at least on member selected from a group consisting of: said document, a profile of auser accessing said document and a browsing history related to said document. 6. The method of claim 5, wherein said document is selected from a group consisting of a webpage, a website, a database record, a screen display. 7. The method of claim 1, wherein each said contextual relation describes at least one of a social relation, a characterizing relation, an ownership relation, a property relation, and an identifying relation. 8. The method of claim 1, wherein at least one of said plurality of contextual relations defines at least one constrain, said executing comprises verifying said at least one known instance comply with said constrain. 9. The method of claim 1, wherein said contextual linkage comprises a group of said plurality of contextual relations. 10. The method of claim 9, said obtaining comprises executing a first of said group for obtaining at least one intermediate instance and executing said at least one intermediate instance along a second of said group for obtaining said at leastone requested instance. 11. The method of claim 10, further comprising outputting an answer graph depicting a contextual relationship of at least one of said at least one intermediate instance and said at least one requested instance. 12. The method of claim 1, wherein at least one of said plurality of contextual relations is a conditional contextual relation defining at least one required instance. 13. The method of claim 12, wherein at least one of said plurality of functionality modules is configured for using said at least one required instance for obtaining said at least one requested instance. 14. The method of claim 12, wherein at least one of said plurality of contextual relations defines an inherence relation between one of said plurality of instance types to another of said plurality of instance types. 15. The method of claim 1, wherein said obtaining comprises using at least one of said plurality of functionality modules for providing a member selected from a group consisting of an advertisement, a rich site summary (RSS), a media file, alink to a contextually related content, and a website; wherein said member is contextually related to said at least one known instance. 16. The method of claim 1, wherein at least one of said plurality of functionality modules is a search module configured for searching at least one instance of an associated said instance type in at least one database. 17. The method of claim 1, wherein at least one of said plurality of functionality modules is a conversion module configured for converting at least one instance of an associated said instance type. 18. The method of claim 1, wherein said a web service is selected from a group consisting of: a representational state transfer (REST) module, a symbolic optimal assembly program (SOAP) module, and a module executing a database query. 19. The method of claim 1, wherein said a code script is selected from a group consisting of: a sub-graph in a transformation language that includes a set of instructions for processing a related data, an extensible style sheet languagetransformations (XSLT), a set of text transformations, a set of regular expressions, a script in a Python language, a script in a Roby language, a script in a JavaScript language, and a precompiled executable script. 20. A system for identifying a contextually related instance, comprising: a graph for mapping a plurality of contextual relations among a plurality of instance types; a list of a plurality of functionality modules, each said functionalitymodule being associated with at least one of said plurality of contextual relations; an input module configured for receiving from a client connected to the system via a network a query defining a contextual linkage between at least one known instanceand at least one requested instance in said graph; and a processor which selects a group of said plurality of functionality modules according to a match between said contextual linkage and a sub-graph of said graph, divides said received query to anumber of single step queries, and iteratively executes at least some of said number of single step queries for obtaining said at least one requested instance, wherein one of said number of single step queries includes a first member of said group withsaid at least one known instance for obtaining at least one intermediate instance and another of said number of single step queries includes a second member of said group with said at least one intermediate instance said at least one requested instance; wherein said functionality module implements at least one of a web service and a code script; wherein members of said group are executed in an order matching dependencies in said sub graph. 21. The system of claim 20, wherein at least one of said plurality of functionality modules is configured for communicating with a network node for said obtaining. 22. The system of claim 21, wherein said network node is selected from a group consisting of a database, a list, and a web server. 23. The system of claim 20, wherein at least one of said plurality of functionality modules is configured for generating said at least one requested instance according to said at least one known instance. 24. A method for obtaining a plurality of contextually related instances, comprising: performing the following by a system which comprises at least one server: identifying at least one object of interest of a first instance type in a dataresource; providing a query defining a contextual linkage between said first instance type and a second instance type; identifying a match between said contextual linkage and a sub-graph of a graph comprising a plurality of contextual relations among aplurality of instance types; selecting a group of a plurality of functionality modules, each said functionality module being configured for providing at least one instance of one of said plurality of instance types; dividing said received query to anumber of single step queries; and iteratively executing at least some of said number of single step queries, wherein one of said number of single step queries includes a first member of said group and used for acquiring at least one intermediateinstance wherein another of said number of single step queries includes a second member of said group with said at least one intermediate instance and used for acquiring at least one instance of said second instance type; wherein each of said pluralityof functionality modules implements at least one of a web service and a code script; wherein members of said group are executed in an order matching dependencies in said sub graph. 25. The method of claim 24, wherein said data resource is selected from a group consisting of a webpage, a screenshot, a word processor document, and a graphic user interface. 26. The method of claim 24, wherein said object of interest is selected from a group consisting of a word, a parse, a paragraph, a website, a link, a media file, and metadata element. 27. The method of claim 24, wherein said data resource is accessed by a browsing user, said formulating is performed according to a user profile of said browsing user. 28. The method of claim 24, wherein said providing comprises selecting said contextual linkage according to said object of interest. 29. The method of claim 28, wherein said data resource is a website, said providing comprises selecting said contextual linkage according to at least one characteristic of said website. 30. The method of claim 24, wherein said providing comprises providing a profile of a user accessing said data resource and defining said contextual linkage according to said profile. 31. The method of claim 24, wherein said data resource is a website, further comprising enhancing a display of said website with said at least one acquired instance. 32. The method of claim 31, wherein said at least one acquired instance are displayed in association with said at least one object of interest. Description FIELD AND BACKGROUND OF THE INVENTION The present invention, in some embodiments thereof, relates to a system and a method for contextual search and, more particularly, but not exclusively, to a system and a method for discovering data according to contextual relation. The emergence of the information age has created a wealth of information that is available electronically. Unfortunately, much of this information is often inaccessible to individuals and data mining systems because they do not know where tolook for it or if they do know where to look, the information may not be found efficiently, inter alia because of the large amounts of information and/or because they do not know when is the right moment to look. One common technique, implemented by traditional keyword search engines, matches words expected to found in a set of documents through pattern matching techniques. Thus, the more that is known in advance about the documents including theircontent, format, layout, etc., the better the search terms that may be provided to elicit a more accurate result. Data is searched and results are generated based on matching one or more words or terms that are designated as a query. Results such asdocuments are returned when they contain a word or term that matches all or a portion of one or more keywords that were submitted to the search engine as the query. Some keyword search engines additionally support the use of modifiers, operators, or acontrol language that specifies how the keywords should be combined when performing a search. For example, a query might specify a date filter to be used to filter the returned results. In many traditional keyword search engines, the results arereturned ordered, based on the number of matches found within the data. For example, a keyword search against Internet websites typically returns a list of sites that contain one or more of the submitted keywords, with the sites with the most matchesappearing at the top of the list. Accuracy of search results in these systems is thus presumed to be associated with frequency of occurrence. During the last years, a number of systems and methods which are based on contextual and semantic maps have been developed. For example, U.S. Patent Application No. 2007/0260598 published on Nov. 8, 2007, provides search engine methods andsystems for generating highly personalized and relevant search results based on the context of a user's search constraint and user characteristics. In an embodiment, upon receipt of a user's search constraint, the method determines all semanticvariations for each word within the user search constraint. Additionally, topics may be determined within the user constraint. For each unique word and topic within the user search constraint, possible contexts are determined. A matrix of feasiblecontext scenarios is established. Each context scenario is ranked to determine the most likely context scenario for which the user search constraint relates based on user characteristics. In one embodiment, the weighting used to rank the contexts isbased on previous user searches and/or knowledge of their interests. Search results associated with the highest ranking context are provided to the user, along with topics associated with lower ranked contexts. Another example is provided in U.S. Patent Application No. 2007/0156669 published on Jul. 5, 2007 that describes methods and systems for extending keyword searching techniques to syntactically and semantically annotated data are provided. Example embodiments provide a syntactic query engine (""SQE"") that parses, indexes, and stores a data set as an enhanced document index with document terms as well as information pertaining to the grammatical roles of the terms and ontological and othersemantic information. In one embodiment, the enhanced document index is a form of term-clause index that indexes terms and syntactic and semantic annotations at the clause level. The enhanced document index permits the use of a traditional keywordsearch engine to process relationship queries as well as to process standard document level keyword searches.SUMMARY OF THE INVENTION According to some embodiments of the present invention there is provided a method for obtaining contextually related instances. The method comprises providing a plurality of functionalities and a map of a plurality of contextual relations amonga plurality of instance types, each the functionally being associated with at least one of the plurality of contextual relations and configured for providing at least one instance of a respective type, receiving a contextual linkage between at least oneknown instance and at least one requested instance, identifying a match between the contextual linkage and a segment of the map, the segment being associated with a group of the plurality of functionalities, and executing the group with the at least oneknown instance for obtaining the at least one requested instance. Optionally, the receiving comprises receiving a search query comprising the contextual linkage. Optionally, the map is a contextual relation graph and the segment being a sub-graph thereof, further comprises converting the contextual linkage to a graph before the matching. More optionally, the sub-graph is an ordered graph comprising a plurality of segments; the obtaining comprises executing each member of the group according to the order in the ordered graph. Optionally, the obtaining comprises obtaining at least one intermediate instance, the executing comprising executing a member of the group with at least one intermediate instance for obtaining the at least one requested instance. Optionally, the at least one known instance appears in a document, further comprising selecting the contextual linkage according to at least on member selected from a group consisting of: the document, a profile of a user accessing the documentand a browsing history related to the document. More optionally, the document is selected from a group consisting of a webpage, a website, a database record, a screen display. Optionally, each the contextual relation describes at least one of a social relation, a characterizing relation, an ownership relation, a property relation, and an identifying relation. Optionally, at least one of the plurality of contextual relations defines at least one constrain, the executing comprises verifying the at least one known instance comply with the constrain. Optionally, the contextual linkage comprises a group of the plurality of contextual relations. More optionally, the obtaining comprises executing a first of the group for obtaining at least one intermediate instance and executing the at least one intermediate instance along a second of the group for obtaining the at least one requestedinstance. More optionally, the method further comprises outputting an answer graph depicting a contextual relationship of at least one of the at least one intermediate instance and the at least one requested instance. Optionally, at least one of the plurality of contextual relations is a conditional contextual relation defining at least one required instance. More optionally, at least one of the plurality of functionalities is configured for using the at least one required instance for obtaining the at least one requested instance. More optionally, at least one of the plurality of contextual relations defines an inherence relation between one of the plurality of instance types to another of the plurality of instance types. Optionally, the obtaining comprises using at least one of the plurality of functionalities for providing a member selected from a group consisting of an advertisement, a rich site summary (RSS), a media file, a link to a contextually relatedcontent, and a website; wherein the member is contextually related to the at least one known instance. Optionally, at least one of the plurality of functionalities is a search module configured for searching at least one instance of an associated the instance type in at least one database. Optionally, at least one of the plurality of functionalities is a conversion module configured for converting at least one instance of an associated the instance type. According to some embodiments of the present invention there is provided a system for identifying a contextually related instance. The system comprises a contextual map for mapping a plurality of contextual relations among a plurality ofinstance types, a list of a plurality of functionalities, each the functionality being associated with at least one of the plurality of contextual relations, an input module configured for receiving a contextual linkage between at least one knowninstance and at least one requested instance, and a computing module configured for selecting a group of the plurality of functionalities according to a match between the contextual linkage and a segment of the contextual map and obtaining the at leastone requested instance by using the group. Optionally, at least one of the plurality of functionalities is configured for communicating with a network node for the obtaining. More optionally, the network node is selected from a group consisting of a database, a list, and a web server. Optionally, at least one of the plurality of functionalities is configured for generating the at least one requested instance according to the at least one known instance. According to some embodiments of the present invention there is provided a method for obtaining a plurality of contextually related instances. The method comprises: a) providing a map of a plurality of contextual relations among a plurality ofinstance types and a plurality of functionalities, each the functionality being configured for providing at least one instance of one of the plurality of instance types, b) receiving a known instance of a first of the plurality of instance types, c)using the map for identifying a group of the plurality of instance types, each member of the group being connected to the first instance type by at least one of the plurality of contextual relations, and d) for each member of the group, obtaining atleast one contextually related instance using a respective the functionality. According to some embodiments of the present invention there is provided a method for obtaining a plurality of contextually related instances. The method comprises identifying at least one object of interest of a first instance type in a dataresource, providing a query defining a contextual linkage between the first instance type and a second instance type, identifying a match between the contextual linkage and a segment of a map of a plurality of contextual relations among a plurality ofinstance types, and using the match for acquiring at least one instance of the second instance type. Optionally, the data resource is selected from a group consisting of a webpage, a screenshot, a word processor document, and a graphic user interface. Optionally, the object of interest is selected from a group consisting of a word, a parse, a paragraph, a website, a link, a media file, and metadata element. Optionally, the using comprises selecting at least one of a plurality of functionalities, each the functionality being configured for providing at least one instance of one of the plurality of instance types and using the at least one selectedfunctionality for the acquiring. Optionally, the data resource is accessed by a browsing user; the formulating is performed according to a user profile of the browsing user. Optionally, the providing comprises selecting the contextual linkage according to the object of interest. Optionally, the providing comprises providing a profile of a user accessing the data resource and defining the contextual linkage according to the profile. More optionally, the data resource is a website; the providing comprises selecting the contextual linkage according to at least one characteristic of the website. Optionally, the data resource is a website, further comprising enhancing a display of the website with the at least one acquired instance. More optionally, the at least one acquired instance are displayed in association with the at least one object of interest. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalentto those described herein may be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition,the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting. Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment ofembodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system. For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a pluralityof software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by adata processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-diskand/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well. BRIEF DESCRIPTION OF THEDRAWINGS The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee. Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of exampleand for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced. In the drawings: FIG. 1 is a schematic illustration of a system for identifying instances which are contextually related to a given instance, according to some embodiments of the present invention; FIG. 2 is a flowchart of a method for identifying one or more instances which are contextually related to a known instance, according to some embodiments of the present invention; FIG. 3 is a schematic illustration of an exemplary contextual map graph depicting a contextual relation between two instance types, according to some embodiments of the present invention; FIG. 4 is a schematic illustration of a contextual relation that connects between two nodes and an additional contextual relation which is connected to an additional node; FIG. 5 is a schematic illustration of an exemplary contextual map graph depicting contextual relations and type nodes of a contextual map that maps social networks, according to some embodiments of the present invention; FIG. 6 is a schematic illustration of a sub-graph that is matched according to an exemplary one-step query, according to some embodiments of the present invention; FIG. 7 is a schematic illustration of an exemplary sub-graph; FIGS. 8, 9, and 10 are schematic illustrations of query graphs which are generated according to exemplary multi-step queries, according to some embodiments of the present invention; FIG. 11 is a schematic illustration of a segment of a contextual map graph that defines, inter alia, a set of constrains, according to some embodiments of the present invention; FIG. 12 is a schematic illustration of a segment of the contextual map that depicts an inheritance relation between an ""artist"" type node and a ""person"" type node, according to some embodiments of the present invention; FIG. 13 is a schematic illustration a method for enriching a display of a resource of information, such as a webpage or a database record display, according to some embodiments of the present invention; and FIGS. 14-17 are screenshots of an exemplary graphical user interface (GUI) that that is popped of in response to one or more objects of interest in various webpages, according to some embodiments of the present invention.DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION The present invention, in some embodiments thereof, relates to a system and a method for contextual search and, more particularly, but not exclusively, to a system and a method for discovering data according to contextual relations. According to some embodiments of the present invention, there is provided a method for obtaining contextually related instances. The method may be used for obtaining contextually related data for search engines, browsing enhancement add-ons,data mining applications, and/or data analysis tools. The method may also be used for obtaining contextually related data from web based applications, business software, location services, mobile services, and/or knowledge management systems. Themethod is based on a contextual map, such as a graph, that maps contextual relations among instance types and on a list of functionalities that allows the obtaining of instances of a first type that is contextually related in the contextual map to asecond type of one or more known instances. Each one of the contextual relation of the contextual map is associated with one of the functionalities. First, a query that includes a contextual linkage between instance types and a known instance of one of the instance types is received. The query may be defined by a user and/or a computing unit, such as a search engine, a website, and/or a browsing add-on. Optionally, the query is provided via a computer network, such as the Internet, from a remotely located network node. Then, amatch is identified between the contextual linkage and a segment of the contextual map. As further described below, the contextual map is optionally a contextual relation graph and the query may be converted to a query graph and matched with a sub-graphof the contextual relation graph. The match allows the obtaining of one or more contextually related instances by executing functionalities which are associated with the segment. According to some embodiments of the present invention, there is provided a method for obtaining instances which are contextually related to one or more objects of interest, such as words, paragraphs, and/or media files of a data resource, suchas a webpage. The method may be implemented using an add-on that is installed on a browser and allows the processing of each downloaded webpage. First, one or more objects of interest of a first instance type are identified in a data resource. Theseobjects of interest may be selected according to characteristics of the webpage, operator definitions, and/or operations of the browsing user. Then, a query that defines a contextual linkage between the first instance type and a second instance type isformulated. Optionally, the data resource is a webpage and the objects of interest are words and/or images thereof. The second instance type may be types of related instances, for example, if the object of interest is a brand of a mobile phone, thesecond instance types may be a store that sells the mobile phone, a celebrity that owns the mobile phone, a specification of the mobile phone, and/or an image of the mobile phone. In such an embodiment, the query may be formulated according to a profileof a browsing user that accesses the webpage and/or according to the type of the website. For example, the query may be for instances which are contextually related to the fields of interest of the user and/or to characteristics thereof, such asgeographic information, profession, age, marital status, and the like. Now, after the query is formulated, a match between the contextual linkage and a segment of a contextual relations map is found. The contextual relations map is optionally definedas outlined above. Then, the match is used for acquiring instances of the second instance type. Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods setforth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways. Reference is now made to FIG. 1, which is a schematic illustration of a system for identifying instances which are contextually related to a given instance, according to some embodiments of the present invention. The system 100 optionallyidentifies one or more instances of a requested instance type that is connected to an instance type by one or more contextual relations of the contextual map. As used herein an instance a reference, such as a mark, a uniform resource locator (URL), atag, a label, and/or a character string that define an actual object, such as an article, a thing, a title, a property, a characteristic, and a name. As used herein an instance type means a mark, a tag, a label, and/or a character string that may beused to define a group of instances. For example, an instance may be a name such as ""Britney Spears"", an object, such as ""Golf"", a property, such as ""window"", and a characteristic, such as ""Blonde"" and an instance type may be one of the following typesa person, a place, an animal, a movie, a product, a characteristic, a property, prototype for an I think that we should use a different word here instance, or any other classification of an instance. The system 100, which is optionally implemented by on one or more servers which are connected to a computer network 101, such as the Internet, comprises a contextual data structure 102, such as a contextual map and/or a contextual graph thatmaps contextual relations that associate among a plurality of instance types and may be referred to herein as a contextual map 102. As used herein, a contextual relation means a simple relation between two instance types that is involving, or dependingon a context or a part of a complex relation among a plurality of instance types that is involving, or depending on a set of contexts, for example a conditional contextual relation in which the one contextual relation depends on other contextualrelations or on the existence of related instances of other type nodes. For example, a contextual relation may describe a social relation, a characterizing relation, an ownership relation, a property relation, and an identifying relation. The system 100 further includes a list of a plurality of functionality descriptors 103 which may be referred to herein as a functionality database 103. Each functionality descriptor has an association with a segment of the contextual map 102,optionally as further described below. For example, of the contextual map 102 is a graph, the functionality descriptor has an association with a sub-graph of the graph. Furthermore, each functionality descriptor has a specific binding to a data sourceand/or service which may be referred to herein as functionality. Each one of the functionalities provides one or more output instances in response to one or more input instances. The input and the output instances are of one or more of the plurality of instance types which are mapped in the contextual map 102. An example for a functionally may be a search module that is designed for searching instances of a requestedtype in a certain database, such as a website, according to a received instance of a given type where the given and the requested types are contextually related. Optionally, a functionality descriptor is associated with a context relation between two instance types, for example between an item and a related property, such as a product-cost relation, a product-description relation, a product-picturerelation, and a product-seller identification (ID) relation, etc. Such a functionality descriptor may be described using a simple function in any modern language, such as Microsoft .Net Language. For example, the functionality descriptor may beassociated with a search module that is optionally designed to retrieve a description of a movie when it receives a respective title. In some embodiments of the present invention, the functionality descriptor may be associated with a functionality that is implemented as a web service, such as a representational state transfer (REST) module or a symbolic optimal assemblyprogram (SOAP) module, a module that is designed to execute a database query, such as an structured query language (SQL), a segment in a transformation language that includes a set of instructions for processing a related data, such as a set of graphtransformations, an extensible style sheet language transformations (XSLT), a set of text transformations, and/or a set of regular expressions, a script in a language such as Python, Roby, JavaScript, and/or any precompiled executable script that may beused for processing the data, for example a dynamic link library (DLL). Optionally, each functionality descriptor is a record that includes and/or refers to one or more of the following: a field that describes the publisher of a service and/or a data source; a testing module for testing the functionalityperiodically, occasionally, and/or according to an operator intervention; a documentation record; a list of links to databases and references; one or more identification tags; and a help file for explaining how to use the functionality. As described above, each one of the functionalities is defined according to a segment, such as a sub-graph, of the contextual map 102, for example a certain contextual relation that maps a connection between two different instance types. Forexample, a functionality that is associated with the contextual relation ""X is written by Y"" where the instance type of X is a book and the instance type of Y is an author or a person, is a search function that is defined to search for an answer in acertain database, such as a website and/or an online knowledge base, such as www.amazon.com. Optionally, one or more of the functionalities are configured for generating instances of certain type according to one or more known instances. For example, a functionality is defined according to a contextual relation ""X dollars worth YEUROS"" where the instance type of X is dollar and the instance type of Y is EURO. The functionality is defined as an exchange function that accesses an online currency exchange services, such as XE.com, com for the answer. Optionally, one or more of the functionalities are configured for identifying documents which are contextually related to the one or more known instances and/or to a combination thereof. For example, a functionality is defined to retrieveadvertisements which are contextually related to a certain consumer good in response to an instance such as a title that depicts a certain product or a certain service, such as antivirus or law services in response to an instance that describes a relatedneed such as virus protection and/or negligence suit. Other documents, such as media files, database records, and/or rich site summary (RSS), which are contextually related to the one or more known instances, may also be retrieved. Optionally, one ormore of the functionalities are configured for identifying links to websites which are contextually related to the one or more known instances and/or to a combination thereof. The system 100 further comprises an input module 104 for receiving a query, such as a line of inquiry or search indicia that include one or more instances of a known type and a request for one or more contextually related instances of arequested type. Optionally, the query defines a contextual linkage between the known type and the requested type. Optionally, the request is received from a requesting entity, such as a network node 106, for example a search engine, a web server, anadvertisement server or a system operator, or a client module 108 that in installed on a client terminal 110, such as a personal computer or a mobile phone, optionally as further described below. As used herein a client terminal means a personalcomputer, a laptop, a mobile device, for example mobile phone and/or a personal digital assistant (PDA), and/or any device that is designed to be connected to the network 101 and operated by a user 109. It should be noted that though only two networknodes 106, 107 are depicted in FIG. 1, the system may be connected to any number of network nodes, for example a plurality of client nodes 107. The system 100 further includes a computing module 105, which may be referred to herein as a context engine 105, for using the contextual map 102 for identifying one or more functionalities of the functionality database 103 for obtaining thecontextually related instances. Optionally, the context engine 105 converts the received query to a graph, which may be referred to herein as a query graph, according to the aforementioned contextual linkage, and identify a match thereof with a segment of the contextual map102. Optionally, as further described below, the context engine 105 implements one or more graph reasoning algorithms according to the contextual relations of the segment of the contextual map. Optionally, graph reasoning algorithms combine contextualrelations to produce a flexible and/or extensible framework that allows the obtaining of contextually related instances from different sources and/or by using different services. Optionally, the contextually related instances may be a link and/or a file. Optionally, the link is to an image and/or a video clip that depicts content that is contextually related to the known instances of the query. In such an embodiment,the system 100 may retrieve contextually related images and video clips in response to the query. Optionally, a contextually related instance may an advertisement and/or a link thereto or a file thereof. Optionally, the content of the advertisement is contextually related to the known instances of the query. In such an embodiment, thesystem 100 may retrieve contextually related advertisements in response to the query. Optionally, the contextually related instances may be a rich site summary (RSS) source. Optionally, the RSS source refers to content that is contextually related to the known instances of the query. In such an embodiment, the system 100 mayretrieve contextually related RSS sources in response to the query. As further described below, the query graph maps a number of contextual relations; each may connect between two different types along the contextual linkage. For clarity, every instance that is acquired according to the query graph and is notthe given instance or one of the requested contextually related instances may be referred to herein as an intermediate instance. In such cases, the context engine 105 may use one or more of the functionalities for obtaining one or more instances of theintermediate instances. The intermediate instances may be used, with respective functionalities, for allowing the context engine 105 to acquire the requested contextually related instances or more intermediate instances for obtaining the requestedcontextually related instances. In an optional manner, the system 100 delivers the contextually related instances to the requesting entity 106, optionally automatically, after an iterative process. Optionally, the system 100 further deliversintermediate instances which have been acquired by the context engine 105 during the iterative process. Optionally, in order to acquire one or more instances, the context engine 105 may search for a relationship between two or more functionalities in the functionality database 103. For example, the context engine 105 may use a currency exchangefunctionality to convert prices of items which have been acquired using search functionality. As a result, the context engine 105 may acquire a price of a certain product in any requested currency. Reference is now also made to FIG. 2, which is a flowchart of a method for identifying one or more instances which are contextually related to a known instance, according to some embodiments of the present invention. The method 200 isoptionally used for identifying one or more instances of an instance type which are connected by contextual relations of the map to an instance type of a known instance. First, as shown at 201, a contextual map 102 that maps contextual relations amonginstance types, such as the aforementioned contextual graph, for example as shown at 102, is provided. Then, as shown at 202, a list that includes a plurality of functionalities, optionally, as shown at 103, is provided. Now, as shown at 203, a querythat includes a known instance and a contextual linkage between the instance type of the known instance and an instance type of contextually related instances is received, optionally via the network 101, as shown at 104. Then, as shown at 204, a matchbetween the query and a segment of the contextual map is identified. Optionally, as described above, the contextual map is a graph. In such an embodiment, the query is converted to a query graph and matched with a sub-graph of the contextual map graph. As described above, contextual relations, which are mapped by the contextual map, are associated with functionalities of the functionality database 103. The match allows the identification of a group of functionalities that may be used for obtaining thecontextually related instances which are defined in the query, as shown at 205 and 206, optionally as outlined above and described below. Optionally, as shown at 207, some of the identified functionalities are used and/or identified in an iterativeprocess, optionally as further described below. In such an embodiment, a sub-group of functionalities is used for obtaining intermediate instances which are used for obtaining the contextually related instances and/or additional intermediate instancesfor an additional sub-group of functionalities. For example, a name of a director of a given movie, which is acquired using a first functionality, may be used for obtaining other movies he made using a second functionality that is designed to receive anactor's name and to retrieve a list of movies he made. Context Map Graph Reference is now made, once again, to FIG. 1 and to FIG. 3, which is a schematic illustration of an exemplary contextual map graph depicting a contextual relation between two instance types. As described above, in some embodiment of the presentinvention the contextual map 102 is a contextual map graph. The contextual map graph 300, which is optionally a directed graph, includes nodes, as shown at 301, 302 that represent instance types and an edge that connects between the nodes 301, 302, asshown at 303, and represents a contextual relation. For clarity, a node in the graph may be referred to herein as a type node. For example, the contextual map graph 300 of FIG. 3 depicts an ownership contextual relation between a person and a dog. Optionally, each node in the graph is tagged with a unique identification tag, such as a universal resource identifier (URI). Optionally, the contextual map 102 is an ordered graph in which nodes appear in manner that enables the conversion of between documents, such as extensible markup language (XML) documents, and common language runtime objects and vice versa, forexample in an XML serialization. Optionally, the relative order of every two nodes is stable and therefore not changed during the activity of the context engine 105. The graph, which is described by the contextual map 102, satisfies one or more of the following constraints: a type node may be connected to any number of contextual relations, for example 0, 1, 2, 3, 4, 5, 10, 100, 1000, and 10000; a type node is not directly connected to another type node; a contextual relation has one and only one outgoing link to a type node; and a contextual relation may link to any number of contextual relations. Optionally, there is no distinction between a type node or a contextual relation and a graph, which may be referred to herein as a singleton graph, containing only such a node or a contextual relation. Optionally, a graph contains at least one type node and contextual relations. Optionally, the type node is data structure that includes the following fields: Type--an instance type, such as a person, optionally as described above. URI, possibly empty. One or more references, such as links to contextual relations,possibly empty. As further described below. The references, which may be represented as a list of links, may list inward and outward links which are related to the type node. Typed-value--a field, possibly empty, for allowing the filtering results. The field includes a string, a number, and/or a real object, such as a .net object, for example an instance of a windows dialog class. For example, the query?Known^Person[/Property^Name==""John Dow""] fetches all the type nodes with a Type that equals to""Person"" and has reference to a contextual relation with a Type=""Property"" and a reference to a type node with a Type=""Name"" and a Typed-value=""John Dow"". Optionally, a contextual relation is a data structure that includes the following fields: Type--aninstance type, such as a property, such as a friend of relation, optionally as described above. URI, possibly empty. One or more references, such as links to contextual relations or type nodes, possibly empty. Optionally, the contextual relation is stored as an intermediate node between two type nodes in the graph. In such an embodiment, the graph comprises edges, which may be referred to herein as links, which serve as connectors between differentnodes in the graph. A link optionally includes a pointer to a node and an index that is used for defining an order between two or more sibling nodes of a parent node. The process of adding a link from a node N to a node D consists of adding an inwardlink pointing to the list of inward links of node D and adding an outward link to the list of outward links of node N. As describe above, a contextual relation may be part of a complex relation among a plurality of instance types that is involving, or depending on a set of contexts. In order to describe such a complex relation, a contextual relation may beconnected to one or more additional contextual relations. For example, as shown at FIG. 4, which is a schematic illustration of a contextual relation 313 that connects between two nodes 311, 312 and an additional contextual relation 314 that isconnected to an additional node 315. The association between two or more contextual relations allows the generation of a conditional contextual relation that defines a combination of contextual relations. For example, FIG. 4 depicts the conditionalcontextual relation ""person Y that is a friend of person X since date with Z"", where X and Y are of a person type nodes and Z is a date type node, as shown at 316. Optionally, using the exemplary query methodology below, such a query may be presentedas: FriendOf/Since^Date==""1/12/08""]^Person where Z=1/12/08. It should be noted that a conditional contextual relation may combine any number of contextual relations. For example, a ""person Y that is a friend of person X from W since date Z"", where A, Y, and Z are as described above andW is a type node that defines the characteristic ""acquaintance circumstances"" identifier, such as ""from University"", ""from School"", ""from work"" and the like. The contextual map, which is optionally a directed graph, is used for representing complex contextual information. As outlined above and described below, such complex contextual information may combine information that is represented indifferent databases, websites, services, and functions. The contextual relation between the type instances does not have to define in any source of information and therefore the system 100 and the method, which is depicted in FIG. 2, may be used as atool for obtaining information that is not accessible by via single source of information on the basis of one or more contextual relations. In some embodiments of the present invention, the system 100 allows the updating of the contextual map 102 and/or the functionality database. In such an embodiment, the system operator, a learning module, and/or any user of the system mayupdate the contextual relations and/or the type nodes which are mapped in the contextual map 102 and the association thereof with functionalities of the functionality database 103. Optionally, the system 100 allows the updating and the addition offunctionalities. In such an embodiment, the contextual map 102 may be a dynamic graph in which type nodes may be added to the graph. It should be noted that allowing such an addition may create a graph that contains a number of similar nodes which areidentical in values and contextual relations. For clarity, a node or a graph may be merged into the graph of the contextual map 102 either directly, for example using one or more application program interfaces (APIs) from XML or non-XML sources such asrelational tables. Reference is now made to FIG. 5, which is a schematic illustration of an exemplary contextual map graph 350 depicting contextual relations and type nodes of a contextual map 102 that maps social networks, according to some embodiments of thepresent invention. As described above, the contextual map 102 maps various contextual relations among node types. Optionally, the contextual map 102 or any segments thereof, for example as shown at 450, 451 maps contextual relations which are relatedto social network, such as Facebook.TM., Linkedin.TM., and Plaxo.TM.. In such an embodiment, the contextual relations create complex relations, as described above, for example by combining common social relations, such as a ""Friend of"" relation, asshown at 352, with other relations which are not related to social relationships, such as property relations, for example ""Size of"", as shown at 351, and with node types which are not related to people, such as ""Shoe"" type, as shown at 352. In such amanner, the contextual map 102 may be used for identifying instances which are contextually related to a known instance via a contextual relation that mix between social relations and other relations, such as property relations. For example, thefollowing conditional contextual relation: ""a person Y that is a friend of person X and have shoe size R"" may be used identifying results to the query ""which one of George Bush friends has shoe size 42"" where the known instances ""George Bush"" of a persontype and ""42"" as a size type and the contextual relation is ""Friend of"" and it is connected to a contextual relation ""Size of"". As described above, each one of the functionalities of the functionality database 103 is optionally connected to sub-graph of the contextual map graph 102. For example, the sub-graph that is shown at 451 is optionally connected to a searchmodule and designed to receive a name of a person and to search the website www.facebook.com for his or her friends and the sub-graph that is shown at 450 is optionally connected to the same search module or to another search module that is designed toreceive a name of a person and a date and to search the website www.facebook.com for friends of a person with the received name which are marked as being his friends since the received date. In use, in order to acquire instances of an instance type that is not directly associated with the type of the received known instance; a number of functionalities may be used. As described above, contextual relations of the contextual map 102are optionally associated with one or more functionalities. In such an embodiment, one or more functionalities may be used acquiring intermediate instances which are used, together with other functionalities, for acquiring more contextually relatedinstances. Optionally, the process of executing the functionalities is an iterative process. In such an embodiment, an outcome of one of the functionalities is used as an input for another of the functionalities and so on and so forth. As describedabove, the contextual map 102 may be an ordered graph. Optionally, the functionaries are executed in the order of a segment of the contextual map 102 that describes a contextual linkage between the known instance and the contextually related instanceswhich are defined in the graph. Exemplary Query Methodology Reference is now made, once again, to FIGS. 1 and 2. As described above and shown at 104, the system 100 comprises an input module 104 for receiving a query that includes one or more known instances and a request for contextually relatedinstances. Optionally, in order to allow the context engine 105 to search for the requested contextually related instances, a query methodology is defined. This section defines an exemplary syntax and semantics of a query methodology for the context engine 105. The query methodology allows the user 109 and/or network node, such as an information localization tool, for example a search engine or amapping application, to query for required and optional instances which are contextually related to other instances which hosted and/or documented in separate, optionally unrelated, databases. The query methodology may also be used for defining the aforementioned functionality descriptors. The query methodology optionally supports extensible value testing by allowing a user to formulate functionality descriptors which are associatedwith custom functionalities. Optionally, the query methodology supports resource description framework schema (RDFS) and the basic elements for the description of ontologies, otherwise called resource description framework resource description framework(RDF) vocabularies, see RDF Vocabulary Description Language 1.0, RDF schema world wide web consortium (W3C) recommendation, published on 10 Feb. 2004 and incorporated herein by reference. Such formulated functionality descriptors are optionally addedto the functionality database 103. For clarity, the query methodology includes character tokens and Boolean operators, both sub-sets of the American national standards institute (ANSI) conventions. Optionally, some or all of the following character tokens are defined: ^--defines a ""Targeting to"" step in the contextual map; .about.--defines a back step in the contextual map; ?--defines single step that expects a list of nodes and/or contextual relations; /--define a single step that expects a single type node or a single contextual relation; and [ ]--defines a filter on a type node or a set of type nodes, as further described below. Optionally, some or all of the following Boolean operators are defined as follows: >--defines a ""bigger than"" operator; <--defines a ""smaller than"" operator; <=--defines a ""smaller or equal than"" operator; >=--defines a ""bigger or equal than"" operator; ==--defines an ""equality than"" operator; !=--defines a ""non equal"" operator; &&--defines an ""AND"" operator; and .parallel.--defines an ""OR"" operator. In particular, the query methodology allows the formulating of one-step queries that may be represented as sub-graphs of the contextual map graph. For example, FIG. 6 depicts a sub-graph that is defined according to the following one stepquery: /Property^Title where a root arrow 400 denotes a pointer to a specified type node which is used as a point of reference in the contextual map graph. Optionally, the current arrow 400 points toward a type of a known instance. The one step query defines,according to the root arrow 400, ""a Book X with a title Y"". In use, the context engine optionally matches the graph query with a sub-graph of the context map graph that links between a node type ""title"" and a node type ""Book"" and uses an associatedfunctionality that returns an instance of the type ""title"". Optionally, the query methodology allows the formulating of one step query for a contextual relation. For example, for the sub-graph that is depicted in FIG. 6, the following one step query is defined: /Property In such an embodiment, the one step query is executed on the contextual map graph when the root arrow 400 points toward the node type ""Book"". In such a manner, the one step query defines the query ""all the properties of a Book X"". In use, thecontext engine matches between the query graph and a sub-graph of the context map graph that includes node types ""property"" which are linked from a node type that is pointed by the root arrow 400 and associated with a functionality that returns one ormore instances of the type ""property"". For example, in a sub-graph that is defined as depicted in FIG. 7, the results of the one step query ""/Property"" are instances of an ISDN type, title type, and/or length type. It should be noted that the responseto the query may include any other property that is associated with the type which is pointed by the root arrow 400. In use, a number of functionalities may be used to return all the properties which are connected to the pointed type node with theexemplary contextual relation ""property"", for example a search module that is designed to receive a book title and to search the congress library database for the international standard book number (ISBN) thereof, a search module that is designed toreceive a book title and search the website www.amazon.com for the length thereof, etc. Optionally, the query methodology allows the formulating of multi-step queries that may be represented as sub-graphs of the contextual map graph. In such an embodiment, the context engine 105 optionally divides the query to a number of singlestep queries and iteratively acquires the results of each single step query until the one or more instances which are requested in the multi-step query are acquired. For example, FIG. 8 shows a query graph that is defined according to the followingmulti step query: /FRIENDOF^PERSON/PROPERTY^NAME that is executed when a current arrow 401 points toward the node type ""Person"" and where two steps are combined into one. In this multi step query, the result includes an instance that includes the name of the person who is a friend of theperson that is pointed at by the current arrow 401, and her name is provided as a known instance. Optionally, the multi step query is divided to two steps. The result of the first step, which is an equivalent of the single step query ""FriendOf^Person"",is an instance of a ""person"" type and the result of the second step, which is an equivalent of the single step query ""/PROPERTY^NAME"" from a pointer to the person type node, is an instance of the ""name"" type, which is the requested result of the multistep query. As described above, the multi step query requests for a single instance that is selected according to the requested final type node or the requested contextual relation. Optionally, the query methodology may be used for defining a multi step query that requests for more than one instance, in various types and/or contextual relations. Optionally, the request for a number of instances is converted to a requestfor instances that match with type nodes and contextual relations of a segment of the sub-graph that is derived from the query. Optionally, the context engine is designed for generating an answer graph that depicts the contextual relation between theretrieved instances. For example, FIG. 9 shows a query graph that is defined according to the following multi step query: /FRIENDOF/SINCE^DATE/.about.SINCE/.about.FRIENDOF where the type node ""person"" is pointed at by the current arrow 401 and .about. defines a back step in the answer graph that is built by the context engine 105. In use, the context engine 105 performs four steps. The first step acquires aninstance that is connected to a ""Friend of"" contextual relation. The second step retrieves an instance that matches a node of a ""Date"" type that is connected to the ""Friend of"" contextual relation via a ""Know since"" contextual relation. The third stepis a backward move that instructs the context engine 105 to point toward the ""since"" contextual relation. The final step is a backward move that instructs the context engine 105 to point toward the ""Friend of"" contextual relation. The query methodology allows the formulating of a query for obtaining of a number of instances that match a certain definition, for example using the aforementioned ""?"" token. The result of such a query is a list with one or more sub-graphsthat satisfies the given query. Optionally, the query methodology allows the definition of a query for a certain instance in the list. For example, the query ?FRIEND^PERSON/0 iteratively searches a list that is gathered by the context engine 105 inresponse to the query ?FRIENDOF^PERSON. Reference is now made, once again to FIG. 1 and to FIG. 5. Optionally, the context engine receives a query with one or more filters and restricts the provided results accordingly. Optionally, a query includes a filter that restricts theresults to type nodes which are contextually related to a property and/or a characteristic with a certain value. For example, the query /FRIENDOF[/SINCE^DATE==""1/1/1994""]^PERSON that is equivalent a query graph that is defined in FIG. 10 and may bematched with a sub-graph of the contextual map 102 of FIG. 5, as shown at 450, triggers the context engine 105 to search for all the friends of person X since 1/1/1994. In use, the context engine 105 optionally uses a functionality that is associatedwith a contextual relation that is equivalent to the query /FRIENDOF[/SINCE^DATE]^PERSON and filters instances that define friends of person X which are not defined as friends since 1/1/1994 from the results. A filter may also define a range in which acharacteristic and/or a property may be bounded. A filter may be used to bound results according to more than one range and/or value. The context engine 105 may be used for obtaining instances of types which are equivalent to type nodes in a segment of a context map 105. For example, the context engine 105 may be used for identifying a graph pattern with a number of typenodes and/or contextual relations. In such an embodiment, the context engine 105 may be used for obtaining data that is defined in a query that defines a complex relation such as ""an actor X that played in a movie Y for more than X minutes"", for exampleas follows: /PLAYEDBY[/FOR^TIME]^ACTOR. In use, the input module 104 forwards a query that defines a contextual linkage between a known instance and contextually related instances to the context engine 105. The query is optionally formulated according to the aforementioned querymethodology. The context engine 105 matches between a query graph that is defined according to the received query and a sub-graph of the contextual map graph. Now, after the sub-graph has been matched, the context engine 105 accesses the functionalitydatabase 103 and selects one or more of the functionality descriptors according to the sub-graph. Reference is now also made to FIG. 11, which is a schematic illustration of a segment 550 of a contextual map graph that defines, inter alia, a set of constrains for executing a certain functionality, according to some embodiments of the presentinvention. As describe above, the contextual map graph includes contextual relations that connects between various type nodes. Optionally, one or more of the type nodes of the contextual map graph define one of more constrains, which may be referred toherein as conditions, and one or more of the contextual relations thereof define conditional relations. Such condition nodes and conditional contextual relations may be used for defining a certain graph pattern that conditions the ability to use acertain functionality that is associated therewith. As described above, the contextual engine 105 matches between a query for one or more requested instances and a segment of the contextual map 102. In order to acquire the one or more requestedinstances, the contextual engine 105 uses one or more of the functionalities which are associated with the segment or sub-segments thereof. The condition types and conditional contextual relations may define which intermediate instances are required inorder to invoke a functionality that is associated with a sub-segment and/or a segment. Briefly stated, the one or more condition types and conditional contextual relations may define a set of specifications that defines terms for providing instances. Optionally, the condition types and conditional contextual relations are optionally not matched with the received query. In such an embodiment, the condition types and conditional contextual relations are used for defining which functionalities to use. For example, the ""Required"" conditional contextual relation 551 assures that the provided current location has a ""as^GPSCoordinates"" link. In addition, the following ""Required"" conditional contextual relations 552, 553 assures that the""as^GPSCoordinates"" link contains latitude value 554 and longitude value 555. In addition, the condition type 556 assures that the latitude value 554 and longitude value 555 are in a specific range 557, namely in a specific grid square of the world map. Optionally, the condition types and/or the conditional contextual relations are weighted. In such an embodiment, a condition node may define a graded condition range and/or a complex condition that depends on the values of a number ofinstances. In some embodiments of the present invention, a type node, which is referred to herein as an inheritance relation node, is used to define an inheritance relation among two or more instance types. In such an embodiment, the inheritance relationnode defines a derived type node that inherits the instance types and the contextual relations of another type node, which may be referred to herein as a base node. The derived type node may be connected via other contextual relation to other instancetypes. For example, FIG. 12, which is a schematic illustration of a segment of the contextual map 102, depicts an inheritance relation between an ""artist"" type node and a ""person"" type node, according to some embodiments of the present invention. Insuch an embodiment, whenever an instance that defines an artist is matched with the contextual map 102, as described above, the contextual relations of a type node ""person"" are checked as if they where the contextual relations of the type node ""artist"" A Plurality of Functionalities Optionally, a number of different functionalities are associated with a certain segment or a sub-segment. In such an embodiment, each one of the functionaries may be weighted according characteristics of the service and/or the data source thatis related thereto, for example, a rank, such as the page rank of the data source, the answer retrieval speed, the access cost, a rating which is provided by the operator, and/or a statistics rank which is determined, optionally dynamically, according tothe feedbacks which are received by the users and/or the operator, retrieval success rates, and/or usage rates. Optionally, each functionality descriptor in the list is associated with a record that defines the rank thereof. Data Expending Feature In some embodiments of the present invention, the context engine 105 is designed for obtaining information that is related to one or more known instances and/or contextual relations. In such an embodiment, the context engine 105 receives aquery with one or more instances and contextual relations and matches it with a segment of the contextual map, as described above. The context engine 105 can then use the contextual map to find more instances which are contextually related to the knowninstances and/or contextual relations. A query for receiving more information that is related to a certain instance and/or contextual relation may be referred to herein as an expand query. For example, the context engine 105 may receive an expand queryfor the contextual linkage ""John Doe, which is a friend of Jane Doe"", that may be presented as a segment in the contextual map 102 that is depicted in FIG. 5, as shown at 451. The context engine 105 may use the contextual map 102 for finding all or someof the instances which are contextually related to the received instance, for example the FacebookID of John Doe 452, his age 453, the name of his dog 454, and/or the shoe size of one of his friends, as shown at 351 and described above. Each one ofthese instances may be acquired using a respective functionality that is associated with respective contextual relations in the contextual map. In use, the context engine uses known instance which have been received via the input module and/or instancesthat have been provided by other functionalities. For example, a functionality that provides names of friends of a person on the basis of the person's name may be used to provide a name of one or more of the friends. The functionality may require theFacebookID 453 of the person. The context engine may then activate another functionality for obtaining the requested FacebookID 453 from the website www.facebook.com. The context engine 105 may use the names of his friends with other functionalities inorder to provide their addresses, job titles, age, and the like. Optionally, the results which are retrieved to a certain expand query may be limited. Optionally, a depth filter that limits the depth of instance types in the contextual map defines a threshold depth that limits the retrieved instances, forexample a 1, 2, 3, 4, 5, 10, 50, 100, 1000 contextual relations. Optionally, a quantity filter that limits the number of instances which are retrieved limits the retrieved instances, for example a 1, 2, 3, 4, 5, 10, 50, 100, 1000 contextually relatedinstances. Optionally, a period filter that limits the period during which instances are retrieved limits process, for example a 1, 2, 3, 4, 5, 10, 50, 100, 1000 seconds. Exemplary Applications Reference is now made, once again, to FIG. 1. As described above, the system 100 is designed to receive query that defines a known instance of a first type and a contextual relation thereof with at least one instance of second. As describedabove, the system 100 may be connected, optionally via the network 101, to one or more network nodes 106, 107, such as a server 106, for example a search engine, a data mining system, a website server, and/or any information localization tool and/or to aclient node 107, such as a client module 108, for example a search module or browsing enhancement add-on which is installed on a client terminal 110. In such embodiments, the client module 108 and/or the network node 106 generate or forward queries tothe input module 104 and optionally receive the results of the queries therefrom, optionally as further described below. In some embodiment of the present invention, the client module 108 is a browser extension. The browser extension is designed to enrich webpages with relevant content that is acquired using the system 100, optionally as described above. Reference is now also made to FIG. 13, which is a schematic illustration a method for enriching a display of a resource of information, such as a webpage or a database record display, according to some embodiments of the present invention. Themethod, which is described in FIG. 13, is optionally performed by the aforementioned browser extension. First, as shown at 601, a resource of information, such as a webpage, is received. Optionally, the received resource of information is a webpagethat is downloaded by a browser, such as a Microsoft Internet Explorer.TM. (IE), Firefox.TM. browser, Netscape Communicator.TM. window, Safari.TM. and/or a Flash and/or Silverlight.TM. supporting browser. Then, as shown at 602, the receivedresource of information is analyzed and one or more objects of interest are identified therein. As used herein, an object of interest means a word, a string, a sentence, a tag, and/or a metadata object. Optionally, the resource of information is a webpage and the objects of interest are strings in the text and/or the metadata thereof, or the webpage URL. Optionally, the objects of interest are determined by a string analysis module that usesbuilt in dictionaries in local storage and/or caching mechanism and/or word processing techniques such as natural language processing (NLP) techniques, advanced usage of regular expressions techniques, and/or dynamic languages techniques. Optionally,the string analysis module identifies the objects of interest by matching the strings in the text or the metadata of the webpage to a predefined list of strings that is stored in a remote server and defines the objects of interest. Optionally, theidentification process, which is performed by the string analysis module, is adjusted according to the resource of information. For example, when the user is viewing a webpage of www.amazon.com that refers to a music album, text and links of the webpagethat represent the album name, the artist and the price automatically become objects of interest. Optionally, the user selects one or more objects of interest by using the mouse arrow or any other pointing element or device. Optionally, the instancetype of each one of the objects of interest is identified and/or provided in advance. After the objects of interest are selected, they are forwarded, as instances, to a query generation module, as shown at 603, optionally together with their instance type. The query generation module, which is a part of the client module 108,the system 100 and/or an independent feature that is installed on the network node 106 or on the client terminal 110, generates a query that includes the one or more of the identified objects. Optionally, the query generation module is associated with alist of queries, each defined for instances of a certain type or instances of a certain combination of types. In such a manner, different queries may be associated with different objects. For example, the query may be defined to retrieve informationand/or images which are related to a certain movie when the object is identified as a movie title and weather information and/or traffic information when the object is identified as a location. Optionally, the query generation module generates the query according to additional instances and/or contextual relations which are gathered from the related data source information and/or from a user profile that is associated with the user109. The additional instances are optionally used, as described above, with relation to the known instances. Optionally, the user profile, which may be stored on the network node 106 or the client terminal 110, includes instances and/or contextualrelations that are related to the user, the user definitions, the user characteristics, browsing history, the user browsing patterns, and the like Using such information, for example, user's interest, which can be determined from his browsing history orpattern, provides contextual content which is specifically targeted for the user. Such user may be extracted by identifying particular events, locations, and/or products which is searched and/or browsed for by the user, for example a restaurant and/or agiven location that a particular user appreciates. Similarly, interests may be extracted by identifying content within a site that is associated with the user. For example, a user visiting www.MTV.com will get a hint that will point him to page of theband whose album he recently bought. Optionally, the system which is depicted in FIG. 1 and the method that is depicted in FIG. 2, may be used for providing a personalized recommendation to a browsing user. In such an embodiment, the known instances which are provided with thequery are related the profile of the browsing user. In such an embodiment, the query may be defined to retrieve a recommendation that is based on semantic understanding of the interests of the browsing user. Reference is now made to FIGS. 14-17, which are screenshots of an exemplary graphical user interface (GUI) 541, which is optionally a part of the aforementioned client module, for example as depicted in numeral 108 of FIG. 1, that is popped ofin response to object of interest in various webpages, according to some embodiments of the present invention. In FIG. 14, the GUI 541 has been popped up in response to the browsing of the user to a webpage that provides a review of music albums, suchas a webpage of www.amazon.com. In such an embodiment, the aforementioned client module generates or selects a query which has been associated with URL of the visited webpage. The query acquires a recommendation 542 to the music album from a reviewwebsite, optionally from a website, which is selected according to the user profile that is appreciated by her, information about an event 543, such as a concert, that is related to the producer of the album, optionally in an area which is close to heraddress, friends that own and/or sell the reviewed product 544, and/or media files which are related to the reviewed product 545. The information is acquired by using the user information in queries which are submitted as described above in relation toFIG. 2. The user profile allows the aforementioned system and/or method to search for information that is related to friends of the browsing user, for example using a contextual map that is based, inter alia, on social network, as depicted in FIG. 15. In such a manner the object of interest, which is the social network webpage and/or the friends name or user ID may be associated with a query for acquiring information about the friend, for example a recommended present to his upcoming birthday 546. The system and/or the method may also be used for notifying the browsing user whether one or more of her friends are members of the website she is currently visit and/or whether one or more of her friends currently browse the same website. Such anembodiment may be implemented in websites such as www.flickr.com. Optionally, the aforementioned system and/or method may notify the browsing user about an involvement and/or an activity of her friends in the visited website, for example whether one ofher friends uploaded pictures, as shown at FIG. 16, sells a used product, recommended a certain product and the like. In sells websites the GUI 541 may be presented with information that associates between the products and the user and/or her friends,for example as depicted in FIG. 17. Optionally, the additional instances and/or contextual relations are determined according to the internet protocol (IP) address of the user. Such information allows the query generation module to add instances or contextual relations which arerelated to the geographical location of the user and/or to previous information which has been gathered on the user. Now, after the query is formulated, contextually related instances are acquired according to the query, as shown at 604. Optionally, the query is forwarded to the system 100 and the system 100 that identifies the contextually related instances,optionally as described above. The contextually related instances are optionally forwarded to the client terminal that displays the resource of information. The instances and/or the queries may also be forwarded to a central server for monitoringand/or statistics. Optionally, the client module 108 includes one or more of the following components: a user interface (UI) for supporting the adjustment of the client module 108 and/or controlling the functions thereof. Optionally, the UI supports extensive layout, themes and accessibility features; a dissecting module for identifying the objects of interest in a webpage that has been downloaded by a respective browser, optionally as described above in relation to block 602; a data access component--interfacing module for supporting the connection of any data source and the adding of semantic tools, software development kits (SDKs) and rich mapping mechanism, such as XML, XML schema definition (XSD), and extensiblestyle-sheet language transformations (XSLT) and various sources; and a context sensitive hosting module--a communication module for interfacing with the system 100. As described above, the system 100 receive queries, via the network, from a requesting entity, such as the network node 106 and/or the client module 108. It should be noted that the client module 108 and/or the network node 106 may alsodirectly connected to the requesting entity. Optionally, the requesting entity is a context sensitive logging and auditing tool that is used in order to log the important data in the right context for tracking transactions, security testing, and maintenance operations. Optionally, the requesting entity is a security module for implementing security business logic, advanced authentication and authorization mechanism, encryption and other data protection mechanism to prevent sensitive information leakage. Optionally, the requesting entity is profile persistence mechanism which is used for capturing and storing client information. In such an embodiment, the information about each client is stored as a graph in a client database. The graph isoptionally created according to the aforementioned methodology. The system 100 is designed to find instances which are contextually related to a certain client by using a contextual map that is based on client information types and related contextualinformation. Optionally, the requesting entity is business intelligence mechanism which is connected to a large scale data warehouse that supports ongoing and offline online analytical processing (OLAP). In such an embodiment, the system 100 is designed tofind instances which are contextually related to a certain company and/or activity by using a contextual map that is based on business related information types and related contextual information. It is expected that during the life of a patent maturing from this application many relevant systems and methods will be developed and the scope of the term a node, a map, a database, and a network are intended to include all such newtechnologies a priori. As used herein the term ""about"" refers to .+-.10%. The terms ""comprises"", ""comprising"", ""includes"", ""including"", ""having"" and their conjugates mean ""including but not limited to"". The term ""consisting of means ""including and limited to"". The term ""consisting essentially of"" means that the composition, method or structure may include additional ingredients, steps and/or parts, but only if the additional ingredients, steps and/or parts do not materially alter the basic and novelcharacteristics of the claimed composition, method or structure. As used herein, the singular form ""a"", ""an"" and ""the"" include plural references unless the context clearly dictates otherwise. For example, the term ""a compound"" or ""at least one compound"" may include a plurality of compounds, includingmixtures thereof. Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as aninflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example,description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, forexample, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range. Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases ""ranging/ranges between"" a first indicate number and a second indicate number and""ranging/ranges from"" a first indicate number ""to"" a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, whichare, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of variousembodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements. Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embraceall such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims. All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent applicationwas specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to thepresent invention. To the extent that section headings are used, they should not be construed as necessarily limiting."
3|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=33&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Asynchronous programming system|Various embodiments are disclosed herein including systems and methods for managing the asynchronous and parallel execution of computer programs. Embodiments implement asynchronous execution in a distributed environment. Single-threaded execution of multiple routines can proceed without thread blocking. Asynchronous variable and routine classes are provided to facilitate development of asynchronous systems using substantially the same development techniques as used for synchronous systems. In some embodiments, the systems and methods for managing asynchronous execution of programs are applied to workflow processing systems.|"1. A system for developing distributed programs, the system comprising tangible computing hardware configured to execute a workflow processing system comprising: a workflowapplication comprising: a program routine; and a secondary routine called by the program routine, wherein the program routine and the secondary routine are configured to execute asynchronously; a data storage module configured to: define a storage areafor an asynchronous variable, wherein the data module raises an exception in response to an attempt to access the storage area being made prior to a data value for the asynchronous variable being placed in the storage area; determine that the secondaryprogram routine to be executed will access the storage area to use the asynchronous variable; and in response to determining that the secondary program routine will access the storage area to use the asynchronous variable, schedule the secondary programroutine to be executed in response to a data value for the asynchronous variable being placed in the storage area; an error handling module configured to: catch an exception from the secondary routine; and in response to catching the exception,schedule for execution an error handling routine associated with the program routine; and a reconstruction module configured to: reconstruct the state of the workflow application, wherein reconstructing the state comprises returning the application to aprevious application state without causing a change outside of the application. 2. The system of claim 1, wherein the program routine and secondary routine execute on separate threads. 3. The system of claim 1, wherein the program routine and secondary routine execute on a single thread. 4. The system of claim 3, wherein the single thread is not blocked during execution of the program routine or secondary routine. 5. The system of claim 1, wherein the data storage module, error handling module, and reconstruction module are part of a program library, and wherein the program library is one of a Java library, Ruby library, Python library, or C# library. 6. A system for developing distributed programs, the system comprising tangible computing hardware configured to execute a program library comprising: a promise module configured to: reserve a memory block for an asynchronous variable, whereinthe memory block is permitted to be accessed only after the asynchronous variable has been set; throw a program exception in response to an attempt to access the memory block being made before a value is placed in the memory block; determine that aworkflow routine to be executed will access the memory block to use the asynchronous variable; and schedule for execution a callback in response to determining that the workflow routine will access the memory block, wherein the callback to the workflowroutine is to be executed in response to a value for the asynchronous variable being placed in the memory block; an execution queue configured to: receive the callback; store the callback in the execution queue; and place the callback on a call stackin response to the callback being dequeued; and an error handling module configured to: catch an exception from a secondary routine, wherein the secondary routine is initiated by the workflow routine, and wherein execution of the workflow routine doesnot wait for execution of the secondary routine after the workflow routine initiates the secondary routine; and in response to catching the exception, schedule for execution an error handling routine associated with the workflow routine and cancelexecution of the secondary routine and any routines that are a descendant of the workflow routine; wherein the library facilitates development of distributed asynchronous or multi-threaded systems using synchronous coding constructs, and wherein thedevelopment utilizes the promise module, the error handling module, and the execution queue. 7. The system of claim 6, wherein the workflow routine and secondary routine execute on a single thread. 8. The system of claim 7, wherein the single thread is not blocked during execution of the workflow routine or secondary routine. 9. The system of claim 6, wherein the program library is one of a Java library, Ruby library, Python library, or C# library. 10. The system of claim 6, wherein the workflow routine orchestrates execution of atomic actions of a workflow process. 11. The system of claim 10, wherein the workflow routine initiates a second workflow process. 12. The system of claim 6, wherein the workflow routine and secondary routine execute on separate threads. 13. The system of claim 6, wherein the workflow routine and secondary routine execute on separate physical computing devices. 14. The system of claim 13 further comprising a state resumption module, wherein the state resumption module returns the internal state of an application to an internal state of the application during a previous execution, wherein returning theinternal state of the application does not result in duplicating effects outside of the application, and wherein the application comprises the workflow routine. 15. A computer-implemented method for developing distributed systems, the method comprising: reserving a memory block for an asynchronous variable, wherein the memory block is permitted to be accessed only after the asynchronous variable hasbeen set; controlling access to the memory block, wherein controlling access comprises throwing an exception in response to an attempt to access the memory block being made before a value for the asynchronous variable is placed in the memory block; determining that a program routine to be executed will access the memory block to use the asynchronous variable; in response to determining that the program routine will access the memory block to use the asynchronous variable, scheduling for executiona callback to the program routine, the callback to the program routine to be executed in response to a value for the asynchronous variable being placed in the memory block; terminating execution of a workflow application in response to encountering ablockage to further advancement of a workflow executed by the workflow application, wherein the workflow application comprises the program routine; and in response to an event unblocking further progress of the workflow application, reconstructing theprogram state of the workflow application, wherein reconstructing the program state of the workflow application comprises returning the internal state of the workflow application to an internal state of the workflow application before the workflowapplication encountered the blockage, and wherein reconstructing the program state does not result in duplicating effects outside of the workflow application; wherein said method is implemented by a computer system comprising computer hardwareconfigured with a program library, and wherein said library facilitates development of asynchronous or multi-threaded systems using synchronous coding constructs. 16. The computer-implemented method of claim 15, wherein the program library is one of a Java library, Ruby library, Python library, or C# library. 17. The computer-implemented method of claim 15, wherein the program routine executes atomic actions of a workflow process. 18. The computer-implemented method of claim 17, wherein the program routine initiates a second workflow process. 19. The computer-implemented method of claim 15, further comprising serializing the internal state of the workflow application in response to encountering the blockage. 20. The computer-implemented method of claim 19, wherein reconstructing the program state comprises deserializing the serialized program state. 21. The computer-implemented method of claim 15, wherein reconstructing the program state comprises replaying execution of the workflow application up to encountering the blockage. 22. The computer-implemented method of claim 21, wherein the replaying comprises processing a plurality of records of events related to the workflow application, wherein the plurality of records are processed sequentially. 23. The computer-implemented method of claim 15, further comprising scheduling for execution an error handler associated with the program routine in response to catching an exception, wherein the exception is caught and the error handlerexecutes after the program routine has finished execution. 24. The computer-implemented method of claim 23, further comprising cancelling one or more secondary routines initiated by the program routine, wherein execution of the one or more secondary routines prior to cancellation does not blockexecution of the program routine. Description BACKGROUND Companies and organizations often have business processes that are performed on a routine basis. The processes can involve multiple discrete or composite actions, some of which can be performed in any order, others which must be performed inparallel or in some other specific order. Such processes are often modeled as workflows. A workflow can be the orchestration of multiple actions. Computer systems can be used to process workflows and orchestrate the execution of the component actions. In order to facilitate processing of a workflow by a computer system, the workflow can be defined in a workflow definition language (WDL). Graphical tools have been created to simplify the process of defining workflows in various WDLs. BRIEFDESCRIPTION OF THE DRAWINGS Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of thedisclosure. FIG. 1 is a network diagram schematically illustrating an example of a workflow execution service that can provide computing resources to process workflow instances in response to events received from internal and external sources. FIG. 2 is a block diagram illustrating a workflow orchestration server and workflow processing server, in accordance with one embodiment. FIG. 3A is a flow diagram illustrating a sample routine for resuming the program state of a decision module for processing workflows, in accordance with one embodiment. FIG. 3B is a flow diagram illustrating a sample routine for resuming the program state of a decision module for processing workflows, in accordance with one embodiment. FIG. 4 is a block diagram illustrating the interaction between a routine processor, an execution queue, and a variable manager in accordance with one embodiment. FIG. 5 is a flow diagram illustrating a sample routine for processing an asynchronous workflow decision module, in accordance with one embodiment. FIG. 6 is a flow diagram illustrating a sample routine for schedule asynchronous execution of callback functions, in accordance with one embodiment. FIG. 7 is a block diagram illustrating the interaction between an asynchronous routine, a memory heap, and a call stack in accordance with one embodiment. FIG. 8 is a flow diagram illustrating a sample execution pattern involving an asynchronous routine implementing exception-based error handling, in accordance with one embodiment. FIG. 9 is a data structure diagram illustrating the relationships between function calls, in accordance with one embodiment.DETAILED DESCRIPTION Various embodiments including systems and methods for asynchronous processing of distributed programs are described herein. For example, a workflow processing system can be implemented as a distributed system, with multiple components executingon any number of computing devices. A workflow can be the orchestration of multiple actions. Execution of some actions can depend on the results of other actions, and therefore the actions are performed in a series. In some cases, actions can beindependent of each other and can be performed asynchronously, in parallel, etc. Typically, each action of a workflow is atomic, e.g.: each action comprises a single activity. In some cases, an action can be a composite of multiple activities which maybe dependant on, or independent of, each other. Computer systems are often used to process workflows and orchestrate the execution of the component actions. In order to facilitate processing of a workflow by a computer system, the workflow can bedefined in a workflow definition language (WDL). Graphical tools have been created to simplify the process of defining workflows in various WDLs. One problem, among others, presented by this workflow development paradigm is that workflow models created using graphical WDL tools often break down when the modeled workflow is complex. Design of asynchronous workflows using standardprogramming languages, however, can be cumbersome, and the resulting programs difficult to debug. Embodiments described herein facilitate development of stateless asynchronous workflow processing applications using standard programming languages andsynchronous-like code, including exception-based error handling. It should be noted, however, that the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure. Various aspects of the disclosure will now be described with regard to certain examples and embodiments, which are intended to illustrate but not to limit the disclosure. Workflow Processing Environment FIG. 1 is a network diagram schematically illustrating an example workflow execution service 100. The workflow execution service 100 is depicted in FIG. 1 as operating in a distributed computing environment comprising several computer systemsthat are interconnected using one or more computer networks. The workflow execution service 100 could also operate within a computing environment having a fewer or greater number of components than are illustrated in FIG. 1. In addition, the workflowexecution service 100 could include various web services and/or peer-to-peer network configurations. Thus, the depiction of the workflow execution service 100 in FIG. 1 should be taken as illustrative and not limiting. The workflow execution service100 includes a workflow orchestration server 110, a workflow processing server 120, an application server 130, and a network 140. The workflow orchestration server 110, workflow processing server 120, and application server 130 can communicate over the network 140. The network 140 can be any wired network, wireless network or combination thereof. In addition, the network140 can be a personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, the Internet, etc., or any combination thereof. Each of the workflow orchestration server 110, workflow processingserver 120, and application server 130 can be a physical computing device configured to execute software applications. In some embodiments, the servers 110, 120, 130 can be configured to execute one or more software applications on the same singlephysical or virtual device, across multiple physical/virtual devices, or any combination thereof. One or more end-user computing devices 150 can communicate with the various components of the workflow execution service 100 over a network 160. The end-user computing devices 150 can be any of a number of computing devices that are capable ofcommunicating over a network including, but not limited to, a laptop, personal computer, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, electronic book reader, digital media player, tablet, and the like. The network 160 can bea network similar to the network 140 of the workflow execution service 100. In operation, the workflow orchestration server 110 can receive notification of an event from the application server 130 or an end-user computing device 150. In response, the workflow orchestration server 110 can load a new instance of aworkflow into a workflow queue. In some embodiments, the specific workflow instantiated in response to the event can depend based on the event, with various events associated with different workflows, etc. The workflow processing server 120 can beconfigured to poll the workflow orchestration server 110 for queued workflows to process, and can receive information about queued workflows that the workflow processing server 120 is configured to process. In some embodiments, the workflow processingserver 120 can expose an API or other method of being invoked by a separate process. For example, the workflow processing server 120 can be configured as a web service. Rather than polling the workflow orchestration server 110 for queued workflows toprocess, the workflow processing server 120 can be invoked remotely through a web method when a workflow is ready for processing. Processing of a workflow can involve determining which activity or activities to execute or schedule for execution based on the current event. Each time the workflow processing server 120 processes an activity, it can generate a command, raisean error, or otherwise initiate a notification to the workflow orchestration server 110, which the workflow orchestration server 110 can save in a workflow history. In some embodiments, the command can be an instruction to execute a program or routine,to start or stop a timer, to send a message to another component or an external process, etc. The workflow process can then be queued for further processing. In one non-limiting example, the application server 130 can be a web server hosting a network resource, such as a retail web site. An operator of an end-user computing device 150 can using a web browsing application to connect to theapplication server 130 and initiate the purchase of a product order through the retail web site hosted by the application server 130. The application server 130 can raise an event or otherwise generate a notification to the workflow orchestration server110 that a purchase is ready to be processed. The workflow orchestration server 110 can instantiate a new purchase workflow and place the workflow instance in a workflow queue, as described in detail below. The workflow processing server 120 can beconfigured to poll the workflow orchestration server 110 at regular intervals to determine whether a purchase workflow needs to be processed. In response to a purchase workflow instance being placed in the workflow queue, the workflow orchestrationserver 110 can respond to a poll from the workflow processing server 120 with information about the purchase workflow instance. In this example, the information can include data related to the customer, product, payment, shipping, etc. The workflowprocessing server 120 can then launch a module of program code designed to process the purchase workflow. The purchase workflow module can determine that the first action to execute is to confirm that the product to be purchased is currently availablein inventory, reserving a unit if it is available or returning a notification if it is not. In response to that determination, the purchase workflow module can issue a command, scheduling the inventory confirmation activity for execution. In some embodiments, the workflow processing server 120 terminates the purchase workflow module after the activity is scheduled, removing all state information from memory. In these implementations, some method of recreating the program statein order to respond to events and schedule the subsequent activities of the purchase workflow can be implemented, such as serialization/deserialization or workflow replay, as described below. In this example, the subsequent activities can includeprocessing of payment information, fraud prevention, notification to warehouse personnel to pack and ship, notification to the customer that the order has been placed or shipped, follow-up by customer service, etc. Depending upon the specific programmingof the purchase workflow module, some of these activities can be required to complete successfully before execution of other activities, such as processing of payment information. Others can be scheduled for execution at any time, such as customerservice follow-up. FIG. 2 illustrates examples of a workflow orchestration server 110 and a workflow processing server 120 in greater detail. As described above, the servers 110, 120 can be individual servers or can represent multiple servers such as might bearranged, for example, in a server bank. The servers 110, 120 can be in data communication with each other over various networks, such as network 140. As described above, network 140 can be the Internet, an intranet, a wide area network (WAN), localarea network (LAN), wireless network, peer-to-peer network, or any other suitable network or combination thereof. In some embodiments, all of the functional components executed in the servers 110, 120 can be executed within a single server or the samepool of servers. The workflow orchestration server 110 can include a workflow execution module 210, one or more workflow queues 220, one or more workflow histories 230, and one or more activity queues 240. The workflow execution module 210 can be executed toorchestrate the implementation workflow instances. Implementation of workflow instances can involve placement of a workflow, or data related to a workflow, in the workflow queue 220. As illustrated in FIG. 2, there can be multiple workflow queues 220,each queue corresponding to a different type of workflow, a different workflow processing server 120, a combination thereof, or any other logical separation of queued workflows, including those determined by load balancing techniques, etc. In oneembodiment, each workflow queue 220 can be employed to temporarily store pointers associated with respective workflow instances. In order to place a workflow instance into a workflow queue 220, a pointer associated with the workflow instance can beplaced in the workflow queue 220, with the workflow instance stored in an appropriate location of an electronic data store, such as a memory, database, hard disk, etc. The workflow execution module 210 can be a computer executable program or collection of programs. Each workflow history 230 can be associated with a workflow instance orchestrated by the workflow execution module 210. The workflow histories230 can each comprise, for example, a list of events that have occurred during the implementation of a given workflow instance over time. The events listed in a given workflow history 230 can include activities executed on behalf of the workflowinstance, such as the scheduling of an activity, the execution of an activity, the completion of an activity, the starting or stopping of a timer, etc. The workflow history can act as a record of the implementation of a workflow instance. The workflowhistories 230 can be stored in an electronic data store, such as a memory, database, hard disk, etc. The various components implemented on the workflow processing server 120 can include decision modules 250. The workflow execution service 100 provides an advantage in that the processing of workflows is much more flexible because the workflowdefinitions are embodied in functional code in the decision modules 250. The complexity and extensiveness of modern day workflows can be adequately represented using functional code that is flexible and can meet all exceptions or permutations ofprocessing and is not restricted to data expressions of WDLs. Each of the decision modules 250 can be configured to identify the activities, actions, or steps to be performed for a specific workflow instance based upon the functional expression of aworkflow definition. Each decision module 250 can embody a workflow definition in the form of functional logic as may be expressed, for example, in terms of programmed code such as Java. Alternatively, the decision module 250 can be programmed usingany one of a number of different existing programming languages. In one embodiment, each different decision module 250 comprises a Java class that may be instantiated multiple times. Thus, there can be many instances of each decision module 250executed by a workflow processing server 120 at any given time. The components executed on the workflow processing server 110 can also include activity modules 260. Activity modules 260 can be executed to perform one or more actions, tasks, or functions that comprise at least a portion of a given workflowinstance based upon a command from a decision module 250. The activity modules 260 can be implemented as Java classes that are each instantiated multiple times in order to handle the workflow processing load from the decision modules 250. An activityqueue 240 on the workflow orchestration server 110 can be associated with each type or class of activity module 260. In response to a decision module 250 issuing a command to execute an activity module 260, the workflow execution module 210 can placethe command in the activity queue 240 to be executed by the corresponding activity module 260 The workflow execution service 100 can be configured to implement workflow instances that perform various functions. For example, a workflow instance can be a process to implement the payment for a purchase of an item though a retail web site. Such a process can involve various actions or tasks, including inputting a credit card number, performing a fraud check on the credit card number, and sending a shipment request to a fulfillment center to implement fulfillment of the order. There can bemany other actions or tasks involved in such a process, where the above actions or tasks are described merely for the purposes of illustration. A workflow can involve various components, persons, applications, and other entities that are involved in theprocessing of data to complete a workflow instance. In the case of the processing of payment for an order, for example, such an order can be processed through various departments and other entities for ultimate authorization and purchase. Workflows canhave hundreds or even thousands of actions. The workflow execution service 100 can be configured to orchestrate hundreds, thousands, or more separate workflow instances in substantially real time, many more than a human could process. In some cases,the multiple workflows can be processed simultaneously. A given workflow instance can involve human intervention at some point, or may be entirely automated. The human intervention can involve interaction with a given activity module 260, a process which can take hours, weeks, or even longer tocomplete. For example, supervisor approval may be in order to issue a refund, etc. In order to prevent the accumulation in memory of workflow instances in various stages of completion that would result from such lengthy delays, the decision modules 250can be process the workflows asynchronously, scheduling activities and then terminating and being removed from memory. The decision module 250 can then be reloaded into memory in response to the workflow execution module 210 of the workfloworchestration server 110 placing the workflow instance back into a workflow queue 220 for further processing. The workflow execution module 210 is configured to respond to requests from the decision modules 250 for workflow instances 212 to implement. Each instance of a decision module 250 polls the workflow execution module 210 to determine whetherthere are any workflow instances represented in a corresponding workflow queue 220 for the decision module 250. In response to the poll, the workflow execution module 210 can examine the workflow queue 220 associated with the decision module 250 todetermine whether there are any workflow instances that are ready to be advanced. In response to a workflow instance being listed in a workflow queue 220 at the time a corresponding decision module 250 polls the workflow execution module 210, the workflow execution module 210 can retrieve the workflow history 230 for theworkflow instance. The workflow execution module 210 can also obtain other data associated with the respective workflow instance from an electronic data store or other location. Once the workflow history 230 and other information embodying the workflowinstance are obtained, the workflow execution module 210 can return the data to the polling decision module 250. After the workflow history 230 and other information embodying the workflow instance are received by the polling decision module 250, the decision module 250 can examine the workflow history 230 in order to determine a next action to bescheduled. Thereafter, the decision module 250 can send a command to the workflow execution module 210 to schedule the next action of the workflow instance, which will be performed by an activity module 260. In some embodiments, the decision module 250can schedule multiple activity modules 260 to implement multiple actions in parallel. In some embodiments, the command initiated by the decision module 250 can be an instruction to execute a program or routine, to start or stop a timer, to send amessage to another component or an external process, etc. Upon receiving the command to schedule execution of an activity, the workflow execution module 210 can proceed to schedule the activity. This may involve placing the workflow instance in an activity queue 240 that is associated with an activitymodule 220. The actions performed by the activity modules 260 can be atomic in nature, involving steps or actions associated with the workflow instance. Alternatively, an activity module 260 may perform actions that are not atomic in nature, such asthe creation of a separate workflow instance that is placed in a workflow queue 220 for further action. Once the activity module 260 has completed performance, it can send a message to the workflow execution module 210 that processing is complete. The workflow execution module 210 can store the message in the appropriate workflow history 230, andproceed to list the workflow instance in the corresponding workflow queue 220 again so that the next action can be determined by the decision module 250. It should be noted that a command issued by a decision module 250 indicates a next action to betaken for a workflow instance. Such action can be an action or task inherent in the workflow, or can comprise closing the workflow instance when the workflow is complete. If the workflow is complete, it is not placed in a workflow queue 220. Each workflow history 230 can list all of the events or other activities that have occurred for a corresponding workflow instance. For example, such events can include scheduling a workflow instance to be processed by a decision module 250 oractivity module 260, the start and completion of processing of a workflow instance, any timeouts that occur with respect to the processing of a the workflow instance, etc. Reconstructing the State of Applications The decision modules 250 can be stateless programs, as described above. By definition, the internal program data of stateless programs does not persist from one invocation to the next. In one embodiment of the workflow execution service 100,the only data that is persisted is the command that is issued by the decision module 250, which becomes part of the workflow history 230. However, the workflow history 230 alone may not provide enough information to determine the next activity toperform. For example, the decision module 250 may perform certain preliminary processing during the determination of a first activity to be scheduled, and can populate program variables with data about the processing. In order to determine lateractivities to schedule, the decision module 250 may require access to that data. Because the decision module 250 is stateless, that data is no longer available. One solution to this problem is to serialize the program state to a data store in between executions of the decision module 250. In this solution, each subsequent invocation of the decision module 250 for a specific workflow will start with adeserialization of the program state. Serialization/deserialization can be expensive, both in terms of the amount of space required to store the program state, and in terms of the network bandwidth required to retrieve the data from the data store ifthe data store is located on a different physical machine than the decision module 250. Moreover, some data structures are unable to be serialized and deserialized efficiently. By creating decision modules 250 that interact with only the workflow history 230 and a limited set of other data that is present when the workflow instance begins, the workflow can be replayed from the beginning on subsequent invocations. Furthermore, the decision modules 250 can be configured to replay the workflow without affecting the overall processing of the workflow instance. The decision module 250 can be conceptualized as a non-deterministic state machine. The next output maynot be determinable based solely on the previous output and/or input. However, by analyzing all prior inputs and outputs and replaying all internal manipulations thereof, the next output (the next activity to be scheduled) can be accurately determined. As described above, in one embodiment the only outputs from the decision modules 250 are commands to execute an activity or series of activities, rather than actual execution of those activities. The commands are sent to the workflow executionmodule 210 of the workflow orchestration server 110 to be placed in the activity queue 240. The commands are executed in response to the workflow execution module 210 executing the activity module 260 associated with the command in the activity queue240. One benefit of this design is that a decision module 250 can begin execution from an initial state during each invocation, whether or not it has already processed a portion of the workflow instance. By inspecting the workflow history 230 that isreceived with the workflow instance, the decision module 250 can continue execution after issuance of a command when there is a record in the workflow history 230 that the command has been successfully executed. Various methods of ignoring, deleting, orotherwise disregarding all previously issued command can be implemented, and the result is that only the newest commands are able to be placed in the activity queue 240 by the workflow execution module 210. Thus, there is no adverse effect such as theissuance of duplicate commands to execute an activity. FIG. 3A is a flow diagram illustrating a sample routine 300a for execution of a stateless decision module 250. The routine 300a resumes the program state of the decision module 250 in accordance with the description above by replaying theentire history of the workflow instance so that subsequent activity commands can be issued. For example, the workflow can instance involve the processing of a product purchase on a retail web site. A decision module 250 developed to process suchpurchases can be implemented on a workflow processing server 120, and can periodically poll the workflow orchestration server 110 for workflow instances to process. At block 305, the decision module 250 receives a workflow instance to process from the workflow execution module 210 of the workflow orchestration server 110. The routine 300a proceeds to block 310, where the first record from the workflow history can be loaded. In some embodiments, the records can be streamed from the workflow history 230, record-by-record. In some embodiments, the entire workflowhistory 230 for this instance of the workflow is received. In this example, a purchase has just been submitted for processing, and therefore the workflow history 230 for this workflow instance may have only one record, indicating the beginning of theworkflow and potentially including parameters or other initialization data. Execution of the routine 300a can then proceed to block 315. At block 315, workflow execution commences under the control of the decision module 250. In this example, a purchase has been submitted and the first activity programmed into the decision module 250 for this workflow is verification that theproduct purchased is in stock. One feature of the workflow execution service 100 is the distribution of processing among different components, and the encapsulation of processing logic within the different components. Therefore, the specifics of how toverify that the product is in stock are not necessarily included in the decision module 250; rather, they are encapsulated in an activity module 260 designed specifically for that purpose. At block 320, the decision module 250 can then issue a command to execute the activity module 260 associated with the inventory confirmation action. The command can be kept in a temporary area of memory until a later step of the routine 300a. Execution of the routine 300a can proceed until block 325, when the decision module encounters the end of an execution path. Note that the end of an execution path may be only temporary, and is not necessarily the termination of the executionpath. In some embodiments, the execution path may be blocked until further processing occurs. For example, when the decision module 250 issues a command in block 320, the decision module 250 may be required to wait for the successful completion of thatcommand before continuing execution. In some embodiments, more than one command may have been issued prior to encountering the end of the execution path at block 315. The routine 300a then proceeds to decision block 330, where the decision module 250 determines whether there are any more records in the workflow history 230 to be loaded. For example, the workflow history 230 may contain a record that thecommand which was issued in block 320 has been scheduled for execution. In such as case, the decision module 340 can remove that command from the temporary area of memory so that the command is not scheduled for execution again. In another example, theworkflow history 230 may contain a record that the command which was issued in block 320 has completed execution. In such a case, the decision module 340 may be able to advance down an execution path that was previously blocked, etc. If the decisionmodule 250 determines at block 330 that these or any other additional records are in the workflow history 230 to load and process, execution of the routine 300a can return to block 310. Otherwise, execution of the routine 300a can proceed to block 335. At block 335, the decision module 250 notifies the workflow execution module 210 of the newly issued commands. In one embodiment, a list of all newly issued commands is transmitted to the workflow execution module 210, which then determineswhich commands to place in the corresponding activity queues 240 and when to do so. Execution of the routine 300a then proceeds to block 340, where the decision module 250 is terminated and all internal state information is lost. A new decision module 250 can be instantiated to poll the workflow execution module 210 todetermine whether there are any workflow instances listed in a respective workflow queue 220 that are to be processed by the decision module 250. Once the inventory confirmation activity has been executed by an activity module 260, a confirmation record can be entered into the workflow history 230. In the present example, once the product to be purchased is confirmed to be in availableinventory, the workflow instance is returned to the workflow queue 220 for further processing, such as receiving payment for the purchase, etc. In response to the polling of the decision module 250, the workflow execution module 210 examines therespective workflow queue 220 to identify whether any workflow instances are ready for processing, and can return the workflow instance for the product purchase, along with the newly updated workflow history 230, to the decision module 250. Processingof the workflow again begins at block 305, and proceeds to block 310, where the first record from the workflow history is loaded. Execution of the routine 300a can then proceed to block 315. At block 315, the decision module 250 does not immediately determine the next action to be taken for the workflow instance. Rather, the routine 300 begins as though no command has been issued and no activity has been executed thus far. In thecurrent example, the decision module 250 determines that the inventory should be checked to confirm that the product to be purchased is in stock. At block 320, the decision module 250 issues the same command that it issued during the previous execution of the routine 300, described above. The command can be placed in a temporary area of memory that is managed by the decision module 250to hold commands prior to transmission to the workflow orchestration server 110. As before, the decision module 250 then encounters the end of the execution path at block 325, because in this example cannot continue until the inventory has beenconfirmed. The routine 300 then proceeds to decision block 330. At decision block 330, the execution path departs from the path taken during the previous execution of the routine 300, described above. The decision module 250 determines whether there are more records in the workflow history to load andprocess. In the current example, the workflow history 230 includes a record that it did not include during the previous execution, indicating that the inventory confirmation activity has completed, and that the product is in stock. The routine 300areturns to block 310 to load the record from the workflow history 230, and proceed to block 315 to determine the next activity that should be performed to process the current workflow instance. At block 315, the decision module 250 determines that the next activity to be performed in the current workflow instance is to receive payment for the product. The routine 300a proceeds to block 320. At block 320, the decision module 250 issues the second command of the current workflow instance that will actually be executed, and the third command overall. The command is for the execution of the payment processing action, as implemented byan activity module 260 developed for that purpose. The command can be placed into the temporary area of memory for commands along with the inventory confirmation command issued previously. The decision module 250 may perform additional processing andissue additional commands before reaching a new end of the current execution path at block 325. The routine 300a then proceeds to decision block 330, where the decision module 250 determines whether there are additional records in the workflow history 230 to load and process. In the current example, the decision module determines thatthere are no additional records, and execution of the routine 300a can proceed to block 335. At block 335, the decision module 250 notifies the workflow execution module 210 of the newly issued command, which in the example is a command to execute the activity module 260 implementing the payment processing activity. Execution of the routine 300a then proceeds to block 340, where the decision module 250 is terminated and all internal state information is lost. A new decision module 250 can be instantiated to poll the workflow execution module 210 todetermine whether there are any workflow instances listed in a respective workflow queue 220 that are to be processed by the decision module 250. In response to the command received from the decision module 250, the workflow execution module 210 can place the workflow instance in the activity queue 240 associated with the activity module 260. When queuing the activity command, theworkflow execution module 210 can record an event in the workflow history 230. The activity module 260 can then proceed to perform one or more tasks associated with the workflow instance. In this example, the activity module 260 can verify that thecredit card number received is valid, that the account associated with the number has sufficient funds to cover the amount charged, etc. Once the activity module 260 has completed its one or more actions or tasks, then the activity module 260 can transmit a message to the workflow execution module 210. Upon receiving such message from the activity module 260, the workflowexecution module 210 can record the completion in the workflow history 230. Thereafter, the workflow execution module 210 can place the workflow instance back into the respective workflow queue 220 for further processing. When the processing of the respective tasks by the activity module 260 was unsuccessful for some reason, the activity module 260 can send a message indicating the failure or error to the workflow execution module 210. The workflow executionmodule 210 can record an event in the workflow history 230 indicating the failure or error, and then place the workflow instance back into the respective workflow queue 220. FIG. 3B illustrates a graph-based routine 300b for resuming a workflow. The routine 300b begins at block 350. As opposed to the routine 300a illustrated in FIG. 3A and described above, the routine 300b of FIG. 3B requires the complete workflowhistory 230 to be available to the decision module 250, in order to determine the status of the commands and other actions represented by nodes in the graph. Execution of the routine 300b proceeds to block 355, where execution of the decision module 250 begins down one execution path of the graph. Returning to the example above, if the decision module 250 is processing a purchase, and the inventoryconfirmation activity has already completed, the decision module 250 can continue down the execution path until the payment processing step is encountered. At block 360, a node corresponding to a decision or other action of the workflow can be reached. For example, the node can correspond to the payment processing command. The routine 300b can then proceed to block 365. At block 365, the decision module 250 can query the workflow history 230 for a record corresponding to the payment processing command. To facilitate such queries, the workflow history 230 can be indexed. In one example, the workflow history230 may contain a record that the payment processing command has completed, or that the command has been scheduled but not completed. In such a case, the decision module 250 could skip the optional block 370 of the routine 300b, where it would issue thecommand if the command were not already issued, and proceed directly to decision block 375. In another example, the workflow history 230 may not contain a record corresponding to the payment processing command. In such a case, the decision module 250would proceed to block 370 of the routine 300b, and issue the payment processing command before proceeding to decision block 375. At block 375 the decision module 250 determines whether to continue down the execution path. For example, a customer service follow-up may need to be scheduled. Execution of the routine 300b can return to block 355 to begin processing thatnode, execution path, determining which commands have been issued and which other events have occurred, issuing new commands, etc. When further advancement down the execution path is blocked, the routine 300b can proceed to block 380. At block 380, the decision module 250 can submit any pending commands for execution to the execution module 210. Execution of the routine 300b then proceeds to block 385, where the routine 300b terminates. When an activity has been completedor another workflow-advancing event occurs, the routine 300b can begin again with one or more new records in the workflow history 230, and the decision module 250 can potentially advance further down the execution path. In some embodiments, serialization/deserialization can be used instead of, or in conjunction with, the replay method described above. For example, failsafe checkpoints can be taken periodically when doing so will not adversely impact systemperformance, while a failure to resume the current state would. Checkpoints can be taken at other times, for example when the serialization of a workflow instance will require less space in a data store than the workflow history would require. In manyimplementations of the workflow execution service 100, the workflow history 230 is located on a physically separate computing device than the decision modules 250 which execute the workflow instance. In such implements, serialization/deserialization canbe a viable alternative when network transmission of a serialized workflow instance is more efficient than network transmission of a workflow history. Distributed Program Processing One method, among others, of implementing a distributed system, such as the workflow system described above, is to embody the workflow decision and activity logic in an asynchronous workflow processing application. Another method ofimplementing a distributed system, such as the workflow system described above, is through the use of parallel programming techniques such as multi-threading. One problem, among others, with implementing such asynchronous/parallel/multi-threadedsolutions is that it can be difficult to code and debug such systems. For example, as described above, workflow systems modeled in WDLs can become cumbersome and often break down when the modeled workflow becomes complex. Development of stateless, asynchronous distributed systems using standard programming languages and synchronous-like code, including exception-based error handling, is described below. This allows programmers to code asynchronous systems usingcode that is similar or identical to the synchronous code the programmers may already be familiar with. It should be noted that the description below applies to parallel and multi-threaded solutions as well. Moreover, although the description belowuses, as an illustrative embodiment, a workflow processing system, it should be noted that the description applies to any distributed system. An asynchronous application can perform the functions of the decision module 250, activity queue 220, and activity modules 260 described above. A workflow execution module 210, workflow queues 220, and workflow histories 230 can still beimplemented to orchestrate multiple workflow instances and definitions. The asynchronous workflow processing application can also leverage the method of resuming a stateless workflow application, described above. The advantageous asynchronous method of implementing a workflow system described herein can reduce or prevent blocking of threads. In one embodiment, the workflow system executes on a single thread, increasing the need for reduced threadblocking. In some embodiments, the workflow system executes in a single process which may not have threads, but which has a single logical thread of execution. Rather than having program instructions and activities execute synchronously, they caninstead be scheduled for execution. Program instructions and activities which depend on other program instructions to populate variables and otherwise perform preprocessing steps can associate callbacks with those variables, and rather than blocking athread while waiting for the instruction to execute, the original instruction can be invoked in response to all variables being ready to be accessed. In one embodiment, the callbacks can be managed by the variables that the program instructionsreference. In one example, an end user initiates the purchase of a product through a retail website. The workflow orchestration server 110 can queue an instance of a purchase workflow, and provide data associated with the instance, for example a workflowhistory 230 and other data provided by the end user, to an asynchronous workflow processing application that is polling the workflow orchestration server 110. The asynchronous workflow processing application can determine actions to execute, scheduleexecution of those actions, and provide the specific logic that will be executed when the action is executing. FIGS. 4, 5, and 6 illustrate the use of several components provided to developers to facilitate asynchronous programming of workflow applications using existing programming languages rather than WDLs. In one embodiment, a library of classes andfunctions are provided to Java developers, enabling development of asynchronous workflow processing applications using Java code and techniques familiar to developers of synchronous applications. In some embodiments, a library or framework can beprovided to developers using the Ruby, Python, or C# programming languages, among others. FIG. 4 illustrates an example asynchronous program during execution. To facilitate asynchronous execution of programs written languages such as Java, a decision module 250 embodying workflow logic can utilize various classes and features of anasynchronous library provided for that purpose, including a routine processor 410, a variable manager 420, and an execution queue 430. In one embodiment, the variable manager 420 can be a class that is instantiated multiple times to manage the operationof multiple asynchronous variables. In some embodiments, the variable manager can be a future or a promise. A variable manager 420 can comprise value storage 422 and a callback table 424. The value storage 422 and callback table 424 can be located inelectronic storage areas, such as memory, a data store, a hard disk, etc. Program instructions referencing an asynchronous variable can have callback functions associated with the variable so that the program instruction can be executed in response to a value being stored in the variable, even though the instructioncan be processed by the routine processor 410 at an earlier time. This technique allows a workflow processing application developer to write program instructions which reference variables that may not have values when the workflow processing applicationinitially executes the instruction. The components illustrated in FIG. 4 can ensure that the instruction will actually execute in response to a value being present. The routine processor 410 can determine when a program instruction references an asynchronous variable, and instead of executing the instruction, the routine processor 410 can associate with the variable a callback to the instruction. Thevariable manager 420 can control access to the value storage 422, throwing an exception or otherwise raising an error in response to an attempt to access the variable being made at a time a value is not present, and executing callback functions listed inthe callback table 424 in response to a value being loaded into value storage 422. A callback can be the signature or memory address of a program instruction to be executed. In some embodiments, a callback can comprise executable code or a signature ofan executable program routine. In some multi-threaded embodiments, a separate thread can begin or continue execution in response to a value be loaded into value storage 422. In some embodiments, various features of the routine processor 410 can beperformed instead by a variable manager 420, and various features of a variable manager 420 can be performed by the routine processor 410. In some embodiments, the value of an asynchronous variable can be set by an external process or other application. Returning to the present example, an asynchronous workflow routine implemented by a decision module 250 can execute in order to process a purchase from a retail web site. The workflow routine can include instructions 411-415. The routineprocessor 410 can load the instructions into its memory space, receive a pointer to the instructions in the memory space of another process, or otherwise obtain access to the instructions. The routine processor 410 can process each instruction anddetermine whether to immediately execute the instruction, schedule the instruction for later execution in the execution queue 430, or associate with a variable manager 420 a callback to the instruction. In the present example, instruction 411 can perform basic setup work, such as loading the buyer's account information. Instructions which do not reference an asynchronous variable and are not marked for asynchronous execution can be executedimmediately. Instruction 412 can reference an asynchronous variable, such as a Boolean true/false flag confirming that the product to be purchased is in stock. In some Java-based embodiments, the workflow application developer designates a variable as anasynchronous variable by annotating the variable, for example with the annotation @AsyncVar. A function or other activity responsible for monitoring the inventory and setting the flag may or may not have executed at this point in the workflow. Therefore the routine processor 410 associates a callback (1) to the instruction with the variable manager 420 responsible for the asynchronous confirmation flag variable. The variable manager 420 can store the callback in the callback table 424. Instruction 413 can invoke an asynchronous function, for example a function which instructs a customer service representative to contact to the customer making the purchase to determine the customer's satisfaction, etc. In some Java-basedembodiments, the workflow application developer designates a function as an asynchronous function by annotating the function, for example with the annotation @AsyncFunc. The remaining instructions of the workflow do not need to wait for the customerservice follow-up to actually be completed, because the process requires human interaction, and can therefore delay the processing of the order. Rather, the routine processor 410 can schedule the function for asynchronous execution (2) with theexecution queue 430 then and move on to processing the next instruction in the workflow without regard as to whether the customer service follow-up is ever completed. Instruction 414 can set the value of an asynchronous variable, such as the inventory confirmation flag referenced by instruction 412. The instruction can send the value (3) to the variable manager 420 responsible for the asynchronousconfirmation flag variable, and the variable manager 420 can then place the value in value storage 422. The variable manager 420 can then execute the callback functions listed in the callback table 424. In the present example, a callback to instruction412 has been stored in the callback table 424, and therefore the variable manager 420 can schedule the instruction for asynchronous execution (4) with the execution queue 430. In some embodiments, instructions which set asynchronous variables, such asinstruction 414, can be scheduled for asynchronous execution with the execution queue 430 rather than executed synchronously. Instruction 415 can be an instruction which does not reference an asynchronous variable or call an asynchronous function. For example, the instruction can update the customer account information loaded by instruction 411. In some embodiments,such instructions can be scheduled for asynchronous execution with the execution queue 430 rather than executed synchronously. As a result of the interactions between the routine processor 410, variable manager 420, and execution queue 430, the instructions 411-415 can have an actual execution sequence of 411-414-415-413-412, even though they are written by the workflowapplication developer in numerical order and processed by the routine processor 410 in numerical order. Instructions 411 and 415 do not reference any asynchronous variable and do not invoke any asynchronous function, and can therefore be executedimmediately after each is processed. Instruction 414 sets the value of an asynchronous variable, and can therefore be executed immediately as well. Therefore, instructions 411, 414, and 415 are executed as they are processed by the routine processor410, in the order in which they are processed. Instruction 413 invokes an asynchronous function, and therefore is scheduled for execution with the execution queue 430, resulting in execution at some time after the routine processor 410 processes theinstruction. The actual delay can range from fractions of a second to many hours or even longer. Finally, instruction 412 waits two separate times be executed: first, it waits for the asynchronous variable that it references to receive a value, andthen it waits in the execution queue 430 behind those instructions which have been placed in the execution queue 430 first, including instruction 413, which was actually processed by the routine processor 410 after instruction 412. In some embodiments, the functions of the routine processor 410 are built in to the classes which define the asynchronous functions. Rather than a single routine processor 410 which processes and schedules each program instruction, theasynchronous function classes themselves, which the program instructions instantiate, invoke, and otherwise interact with, can perform the functions of associating callbacks with variables, scheduling execution, etc. When a decision module 250 executes aprogram instruction related to an asynchronous class, such as invoking a method of the asynchronous class, certain processing can occur which associates callbacks to the method or schedules execution of the method. Program control can then beimmediately returned to the decision module 250 without blocking the thread to actually execute the business logic of the method. In some embodiments, the functions of the variable manager 420 are built into the classes which define the asynchronous variables. Rather than a separate object which controls access to the variable and maintains a callback table, a anasynchronous variable class defining these functions can be instantiated for manipulation as any other variable. Certain processing can occur in response to the manipulations, however, such as throwing an exception with the variable does not contain avalue, executing callbacks the variable receives a value, etc. In some embodiments, some or all of the functions attributed above to the routine processor 410, the variable manager 420, and the execution queue 430 can instead be performed by virtual machine or other runtime framework. FIG. 5 is a flow diagram illustrating a sample routine 500 for execution of an asynchronous workflow processing application utilizing a routine processor 410, a variable manager 420, and an execution queue 430, as described above. In thisimplementation, a stateless, asynchronous decision module 250 determines actions to execute in order to advance the workflow, as described in detail above. For example, the decision module 250 can comprise instructions 411-415, as illustrated in FIG. 4and described above. The decision module 250 can also include implementations of the activity modules 260, or the activity modules 260 can be separate program modules configured to operate in an asynchronous workflow processing environment. Theexecution of the decision module 250 and the management of the data referenced within can occur under the control of a routine processor 410. At block 505, the asynchronous decision module 250 is initialized. Machine-readable code, Java bytecode, source code, or another embodiment of program instructions can be loaded into the memory of the workflow processing server 120, dependingon the specific implementation of the decision module 250 and routine processor 410. The routine 500 then proceeds to block 510, where an instruction of the asynchronous decision module 250 is prepared for processing. The processing can involve parsing the instruction to determine its component parts in order to facilitate theoperation of the routine processor 410 during subsequent blocks of the routine 500. The routine 500 then proceeds to decision block 515, where the routine processor 410 determines whether the instruction references an asynchronous variable. As described above with respect to FIG. 4, the instruction can be one of instruction411-415. If the instruction does reference an asynchronous variable, as instruction 412 does, execution of the routine 500 proceeds to block 535 where the routine processor 410 associates with the variable a callback to the instruction. If theinstruction does not reference an asynchronous variable, as instructions 411, 413, and 415 do not, execution proceeds to decision block 520. At decision block 520, the routine processor 410 determines whether the instruction is a call to an asynchronous function. When the instruction does not invoke an asynchronous function, as instructions 411 and 415 do not, execution of theroutine 500 proceeds to block 525. At block 525, the routine processor 410 can execute an instruction immediately in response to a determination in block 520 that there is no asynchronous aspect to the instruction. Examples of such instructions include instructions 411 and 415,described above with respect to FIG. 4. In some embodiments, even such non-asynchronous instructions can be loaded into the execution queue 430. Returning to block 520, if the instruction does invoke an asynchronous function, as instruction 413 does, execution of the routine 500 proceeds to decision block 540, where the routine processor 410 determines whether the asynchronous functionreferences an asynchronous variable, and if so, the routine 500 executes the processing described above with respect to block 535. If the asynchronous routine does not reference an asynchronous variable, the routine 500 can proceed to block 545 wherethe asynchronous function can be scheduled for execution at the earliest available time by being placed in the execution queue 430. After blocks 525, 535, and 545, the routine 500 proceeds to decision block 530 where the routine processor 410 determines whether there are more instructions to process. If there are more instructions to process, execution of the routine 500returns to block 510. Upon returning to block 510, another instruction can be processed as described above, and execution proceeds to decision block 515, where the routine processor 410 determines whether there are asynchronous variables referenced bythe application. Otherwise, execution proceeds to block 550, where the routine 500 terminates. FIG. 6 is a flow diagram illustrating a sample routine 600 implemented by the variable manager 420 for execution in response to receipt of a value to store in value storage 422. Execution of the routine 600 begins at block 605, where thevariable manager 420 receives a value. For example, in response to instruction 414, described above with respect to FIG. 4, being executed, the value to be stored can be a simple true/false Boolean flag indicating whether or not the product to bepurchased is currently in stock. Execution of the routine 600 then proceeds to block 610. At block 610, the variable manager 420 places the value in value storage 422. In the current example, a Boolean true or false value is placed in value storage 422. Execution of the routine 600 then proceeds to block 615. At block 615, the variable manager 420 processes any callbacks associated with the variable. In the current example, the routine processor 410 registered a callback to instruction 412, which uses the inventory confirmation flag to performfurther processing. The variable manager 420 can retrieve the callback from the callback table 424, and the routine 600 can then proceed to decision block 620. At decision block 620, the variable manager 420 determines whether the instruction associated with the callback references other asynchronous variables. If the instruction does reference other asynchronous variables, execution of the routine600 can proceed to decision block 635, described next. Otherwise, execution proceeds to block 625, described below. At decision block 635, the variable manager 420 determines whether the other asynchronous variables referenced by the instruction have values and are therefore ready to be accessed. If all other asynchronous variables are ready to be accessed,execution can proceed to block 625, described below. Otherwise, execution can proceed to decision block 630, described below. In some embodiments, the variable manager 420 can remove the callback from the callback table 424 and associate with the othervariables a callback to the instruction if there is not one already associated. Execution of the instruction will now depend on the other asynchronous variables referenced by the instruction. Each has a callback to the instruction in its respectivecallback table. In response to those variables becoming available and their callbacks being processed according to the routine 600, the current variable can be consulted to determine wither it has a value and is ready to be accessed. Unless the Booleantrue/false value received in block 605 has been removed from value storage 422, the current variable will confirm that it is available for accessing. If for some reason the Boolean value received in block 605 has been removed from value storage 422, theother variable managers can register with the current variable a new callback to the program instruction, delete the callback from their own callback tables 424, and proceed with execution as described herein. In the current example, there were no other variables referenced by instruction 412, and therefore execution of the routine 600 can proceed from block 620 to block 625. At block 625, the variable manager 410 can schedule the program instructionassociated with the callback for execution by placing it in the execution queue 430. Execution of the routine 600 can then proceed to decision block 630. At decision block 630, the variable manager 410 can determine whether there are more callbacks associated with the current variable. If there are, execution of the routine 600 can return to block 610. In the current example, there are none. Therefore, execution can proceed to block 640, where the routine 600 terminates. Error Handling in Asynchronous Applications Application developers utilizing the asynchronous workflow programming components and techniques described above can implement asynchronous workflow decision modules 250 using their programming language of choice, for example Java. Providinglibraries and components to implement exception-based error handling can further help to make the asynchronous workflow development process simpler by again leveraging techniques that application developers are already familiar with. Exception-based error handling can use special programming constructs, such as try/catch blocks, to trap program exceptions and deal with them gracefully. The application developer places program instructions inside the ""try"" block of thetry/catch block, and the program instructions are automatically associated with an error-handling routine consisting of program instructions placed inside an accompanying ""catch"" block of the try/catch block. In some embodiments, a ""finally"" block canbe included, creating a try/catch/finally block. The program instructions placed in the finally portion can be executed regardless of whether an exception is thrown during execution of one of the instructions in the try block, and regardless of whetherthe program instructions inside the catch block are executed. In some embodiments, the catch block can be omitted, creating a try/finally block. FIG. 7 illustrates an example interaction between a function 710, a memory heap 720, and a call stack 730, such as might occur when processing a try/catch block. The function 710 is an asynchronous function with a try/catch block 712, 714. Theheap 720 can have memory blocks 722, 724, and 726. The call stack 730 can have stack frames 732, 734, 736. Note that the call stack 730 and memory heap 720 refer to the memory structures used by, for example, an operating system to manage execution andmemory resources of threads and processes. The call stack 730 and memory heap 720 do not refer to the generic data structures named stack and heap. When an asynchronous function 710 with a try/catch block 712, 714 is initially executed, it is pushed onto the stack 730, for example at stack frame 736. The catch block 714 can then be sent (1) to the heap 720 until it is needed. For example,the catch block 714 can be stored in memory block 726, or in any other memory block in the heap 720. This is unlike a synchronous execution, where the catch block 714 would be pushed to the stack at frame 734 before any instructions in the try block 712are pushed and executed. In an asynchronous setup, the instructions contained within an asynchronous function 710 are not pushed directly to the stack 730 for execution, but are rather sent to the heap 720 to be scheduled for execution, and only whenthey are executed are they pushed to the stack 730. Therefore, the instructions of the try block are also sent (2) to the heap 720 until they are scheduled for execution. The instructions of the try block 712 can be stored in memory block 724, or anyother memory block. The instructions of the try block 712 can then be linked (3) to the catch block 714, so that when an exception is encountered by an instruction of the try block 712, the catch block 714 can be pushed to the stack 730 in order tohandle the exception. When an instruction in the try block 712 is to be executed, it is pushed (4) to the stack 730. If an exception is thrown during execution of a try block 712 instruction, the instruction is popped from the stack 730 and the catch block 714 ispushed (5) to the stack 730 for execution. In embodiments containing a finally block, a similar procedure is used to link the finally block to the try block 712 instructions and the catch block 714, and the finally block is pushed to the stack 730 afterthe catch block 714 executes, or after an exception is thrown in a try/finally block configuration. FIG. 8 is a flow diagram illustrating an execution pattern 800 that can occur when an asynchronous routine 710 with a try/catch block executes and catches an exception. The execution pattern 800 is discussed with continuing reference to thecomponents illustrated in FIG. 7 and the sample program instructions 411-415 illustrated in FIG. 4. The execution pattern 800 begins at block 805, when an asynchronous routine 710 enters a try/catch block. The execution pattern 800 then proceeds to block 810. At block 810, the catch block 714 is loaded into the memory heap 720. The asynchronous routine 710 can be a method of a class designed to produce this execution path 800, and the class itself can load the catch block 714 into the heap 820during execution of the routine 710. In some embodiments, a separate the routine processor, such as the routine processor 410 described with respect to FIG. 4, can process the individual instructions of the routine 710 and load the catch block 714 intothe heap 720. In some embodiments, the Java Virtual Machine or some other runtime executable or library can process the routine 710 and load the catch block 714 into the heap 720. In response to the catch block 714 being loaded into the heap 720, theexecution pattern 800 proceeds to block 815. At block 815, processing of the instructions in the try block 712 can begin. Proceeding to decision block 820, the asynchronous routine class can determine whether each individual instruction has an asynchronous component, such as a referenceto an asynchronous variable, invocation of another asynchronous routine 710, etc. For example, instruction 412 and instruction 413 have asynchronous components. For instructions of that type, the execution pattern 800 can proceed to block 835, describedbelow. Otherwise, the execution pattern proceeds to block 825, for example in response to the instruction being instruction 411 or instruction 415. At block 825, the instruction is executed immediately because there is no asynchronous aspect to the instruction. If an exception is thrown, the catch block 714 can be executed because the asynchronous routine is still in the process ofexecuting. In some embodiments, the catch block is pushed to the stack 730 in block 810, as well as being sent to the heap 820, specifically to facilitate error handling of program instructions performed synchronously, such as in block 825. In someembodiments, all instructions are sent to the heap 720, associated with the catch block 714 there, and scheduled for execution rather than executed immediately. When an instruction is executed synchronously, as in block 825 above, the execution pattern proceeds to decision block 830 in response to there being no exception thrown. At decision block 830, the asynchronous routine class, Java virtualmachine, or other runtime executable or library determines whether there are additional instructions to process. If so, the execution pattern returns to block 815. Otherwise, the execution path terminates at block 855. Returning to block 820, in response to the asynchronous routine class determining that there is an asynchronous component to the instruction, the execution pattern can proceed to block 835. At block 835, the asynchronous routine class oranother component can associate with an asynchronous variable a callback to the instruction, send the instruction to the heap 720 for scheduled execution, or both, depending on the specific implementation. At some future time the instruction can be executed, either by callback or scheduled execution. The execution pattern 800 can proceed to block 840 if an exception is caught, indicating a program error related either to the instruction or toanother instruction initialized, directly or indirectly, by the instruction. The execution pattern 800 then proceeds to block 845. At block 845, all sibling instructions and functions that are either in the process of executing or are pending are cancelled, as described below with respect to FIG. 9. One all siblings have been cancelled, the catch block 714 can be executedat block 850. In response to an exception being thrown in a synchronous program, the call stack is rolled back until a catch block is encountered, and the catch block is then executed. In asynchronous programs, there is no call stack that tracks each andevery function and instruction that is currently in the process of being executed, because there can be more than one processor executing instructions in parallel, and also because some instructions may not be executed until after the asynchronousroutine has terminated execution and been popped from the stack. An execution tree 900, such as that illustrated in FIG. 9, can facilitate termination of certain in-progress and pending calls in response to an exception being thrown, even in asynchronous and multi-threaded systems The execution tree 900 canbe used to track the execution pattern of an asynchronous or parallel workflow application. In some embodiments, a component of the workflow processing system 100 can utilize the execution tree to determine which nodes are candidates for termination,with the nodes representing separate program routines. Relationships between the program routines can be determined based on the position of the program routines within the tree, and each node in a specific relationship can be a termination candidate. For example, each node that is a child, descendant, or sibling of a node that has a try/catch block can be a termination candidate. The tree begins with a root node 910, which represents the first function or instruction that executed. In the example illustrated in FIG. 9, two functions invoked by the root node 910 are represented by child nodes 920 and 930. Child node 930in turn invoked a single function represented by node 940. Node 920, the other child of root node 910, represents another function that was executed. However, node 920 contains a try/catch block. Node 920 proceeded to invoke three more functions, represented by nodes 950, 960, and 970. Finally, node960 invoked two functions, represented by nodes 980 and 990. In some embodiments, the try block and/or catch block of node 920--or a finally block, or the try, catch, and/or finally block of any other node--may also make calls to other functions whichexecute asynchronously or in parallel, etc. Until each node invoked by a parent node have finished execution, including all descendants thereof, the parent node will remain in the execution tree 900 in order to track its descendant nodes so that they can be cancelled if an unhandledexception occurs. Such a procedure can help to ensure that costly descendant processes do not remain scheduled for execution if, in one example, a parent has thrown an exception, rolled back its state, and been terminated from memory. The costly childprocess may no longer be necessary. Usage of the execution tree can facilitate cancellation of such costly child processes before they needlessly consume system resources. In response to a descendant of 920 throwing an exception, the try/catch block of node 920 can catch the exception and prevent its propagation to the root node 910, which otherwise would jeopardize the entire execution tree 900. In the exampleillustrated in FIG. 9, node 990 throws an exception. None of node 920's descendants has a try/catch block to catch the exception and handle it gracefully. Therefore, each of node 920's descendant nodes are cancelled, and the try/catch block of node 920is executed. In some embodiments, a descendant of node 920 may have a try/catch block, but the node is not positioned to catch the exception. For example, node 950 may have a try/catch block. In some embodiments, node 920 may have completely finishedexecution before any of its descendant nodes begins execution. Even in such embodiments, the catch block of node 920 can be executed when an exception is thrown by one of node 920's descendants. If any of the descendant nodes which are cancelled has acatch block or a finally block, and execution in the descendant node is currently in the try block, the catch and/or finally block can be executed before the node is cancelled. For example, if one of the nodes has a try/finally block with no catchblock, the finally block will execute and the node will be cancelled. In some embodiments, a separate cancellation handler may be implemented, and the cancellation handler for a descendant node can execute instead of, or in addition to, the catch andfinally blocks when the node is cancelled during execution. In one embodiment, the try/catch block automatically includes program instructions to traverse the tree and cancel descendant nodes in response to an exception being caught. In one embodiment, the exception is an instance of a class whichcontains program instructions to cancel nodes as the exception is propagated throughout the tree. In one embodiment, a separate class is available in a Java Virtual Machine, runtime library, or similar collection of system classes. The class can beinstantiated or is automatically instantiated, and traverses the execution tree 900 to cancel descendant nodes in response to an exception being thrown or caught. In one embodiment, the execution tree 900 is an instance of a class which contains programinstructions to cancel, in response to an exception being thrown, all descendants of the node which caught the exception.CONCLUSION Thus, in various embodiments, the systems and processes described herein can model workflow definitions and asynchronously process workflow instances based on those models. Application developers can leverage program design techniques andexception based error-handling that they are familiar with, for example by using standard Java programming tools. Depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out all together (e.g., not all described acts or events arenecessary for the practice of the algorithm). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallelarchitectures, rather than sequentially. The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware orsoftware depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the disclosure. The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an applicationspecific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computingdevices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. The steps of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A softwaremodule can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupledto the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. TheASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal. Conditional language used herein, such as, among others, ""can,"" ""could,"" ""might,"" ""may,"" ""e.g.,"" and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or moreembodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. The terms""comprising,"" ""including,"" ""having,"" and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term ""or"" is used in its inclusive sense(and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term ""or"" means one, some, or all of the elements in the list. Conjunctive language such as the phrase ""at least one of X, Y and Z,"" unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y or Z. Thus, suchconjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y and at least one of Z to each be present. While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices oralgorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits setforth herein, as some features can be used or practiced separately from others. The scope of certain inventions disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning andrange of equivalency of the claims are to be embraced within their scope."
4|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=45&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Hierarchically scoped resettable variables in graphical modeling environments|The illustrative embodiments of this invention are directed to a method, a medium and a system for realizing resettable hierarchically scoped variables in a graphical modeling environment on a computing device. The method includes creating at least one resettable variable in a model within the graphical modeling environment, wherein the resettable variable is hierarchically scoped. The resettable variable is reset to a preset value before or during a subsequent invocation of a part of the model that contains the resettable variable. The graphical modeling environment may be a state diagramming environment or the graphical modeling environment may be a time-based graphical modeling environment.|
5|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=48&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Beverage dispensing system having a cold plate and recirculating pump|A recirculation loop for a beverage dispensing system. The beverage dispensing system has a fluid supply, a cold plate, a valve/manifold assembly, and a bar gun connected to the valve/manifold assembly. The recirculation loop draws off fluid being carried from the cold plate to the valve/manifold assembly and, having a pump as part thereof, pumps some of that fluid to a point just upstream of the cold plate. In this manner, the recirculation loop keeps fluid cool, even when the bar gun is not dispensing beverages therefrom, for long periods of time. That is, the pump runs independent of the bar gun and is typically on all the time, so that fluid in the line from the cold plate to the valve/manifold assembly stays chilled.|
6|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=28&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Combinators|A method of managing a database system that receives N number of requests from one or more nodes in the database system. The N requests are combined before initiating operations to attend to the requests. The number of operations to attend to the requests is reduced and this reduced number of operations is executed.|
7|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=41&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Method, computer, and computer program for speculatively optimizing code|A method, computer, and computer program for speculatively optimizing a code. The method includes speculatively optimizing the code characterized by searching in a predetermined order in at least one dictionary; extracting a value associated with a symbol name from a dictionary using the symbol name as a key; performing optimization to replace a symbol in the code with the value; compiling the code to be compiled including some or all of the optimized code; comparing, in response to detection of a change related to one dictionary among at least one dictionary, an order m in the predetermined order of the dictionary with the detected change to an order n of the dictionary with the extracted value; and invalidating the optimized code in the compiled code associated with the dictionary having the detected change in response to the results from the orders comparison and the type of change.|
8|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=10&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Electronic message systems and methods|Methods and systems to process computer readable electronic messages, such as electronic mail messages or e-mail. Methods and system include auto-tagging based on one or more of statistical machine learning based clustering techniques, custom parsers, and crowd-sourced message tagging. Methods and systems further include relevancy determination based on combinations of features, user-configurable hybrid web browser/e-mail client rendering, tabbed rendering, plug-in based local computational features, implied social graph based decision making, and automatic detection of account settings.|"1. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the first user based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associatedwith the respective electronic messages; wherein the associating descriptive tags with the electronic messages of the first user includes learning electronic message tagging rules based one or more of a statistical machine learning technique and aparser, and associating the descriptive tags with the electronic messages of the first user based on features associated with the electronic messages and the learned electronic message tagging rules. 2. The method of claim 1, wherein: the analyzing includes one or more of, parsing syntactic features associated with the electronic messages, recognizing named entities associated with the electronic messages, recognizing acronyms associatedwith the electronic messages, detecting sentiments expressed within the electronic messages, determining semantic roles associated with the electronic messages, and determining relationships amongst senders and recipients of the electronic messages withrespect to an implied social graph; and the associating descriptive tags with the electronic messages of the first user further includes associating descriptive tags with the electronic messages based on one or more of the parsed syntactic features, therecognized named entities, the recognized acronyms, the sentiments, the determined semantic roles, and the determined relationships amongst the senders and recipients of the electronic messages with respect to the implied social graph. 3. The method of claim 1, wherein the performing includes: extracting information from electronic messages that are tagged with a first descriptive tag; and presenting the extracted information within a user interface associated with the firstdescriptive tag. 4. The method of claim 3, wherein the first descriptive tag, the extracted information, and the user interface correspond to at least one of: online purchases; travel; invitations; newsletters; offers; promotions; scheduled meetings; invoices; online payments; banking/finance; electronic messages awaiting a response from the first user; informational electronic messages that are of high relevance to the first user; and electronic messages that are of high relevance to the firstuser and that are awaiting a response from the first user. 5. The method of claim 3, wherein: the associating descriptive tags with the electronic messages of the first user further includes associating the first descriptive tag with electronic messages that correspond to a message template; theextracting includes parsing information from the electronic messages that are tagged with the first descriptive tag based on the message template; and the presenting includes presenting the parsed information within the user interface associated withthe first descriptive tag. 6. The method of claim 3, wherein the extracting includes parsing information from the electronic messages that are tagged with the first descriptive tag based on user-provided parsing instructions. 7. The method of any one of claims 3 to 6, wherein the performing further includes: providing a user-manipulable control within the user interface to retrieve information from a web site based on the extracted information; and presenting theretrieved information within the user interface. 8. The method of claim 3, wherein: the associating descriptive tags with the electronic messages of the first user further includes clustering the electronic messages of the first user based on features of the respective electronic messages andassociating the first descriptive tag to all electronic messages within a cluster of electronic messages; and the performing further includes extracting information from the electronic messages that are tagged with the first descriptive tag, andpresenting the extracted information within the user interface associated with the first descriptive tag. 9. The method of claim 1, wherein the associating descriptive tags with the electronic messages of the first user further includes: associating a user-identified tag to a user-identified electronic message; identifying features of theuser-identified electronic message; and associating the user-identified tag to other electronic messages that have features similar to the features of the user-identified electronic message. 10. The method of claim 3, wherein the performing further includes: generating the user interface as a web-page-like interactive user-interface based at least in part on metadata associated with the electronic message. 11. The method of claim 10, wherein the performing further includes: aggregating a plurality of the web-page-like interactive user-interfaces in a tab-view. 12. The method of claim 1, further including: hosting a user-programmable electronic messaging client; and performing the analyzing and the performing within the hosted user-programmable electronic messaging client. 13. The method of claim 12, wherein the hosting includes: hosting a Python-extensible thick-client electronic messaging system. 14. The method of claim 12, wherein the hosting includes one or more of: using a browser plug-in; and using an application shell. 15. The method of claim 1, wherein the performing includes: permitting the first user to search the electronic messages of the first user based on a file name extension type associated with attachments to the electronic messages and informationtagged within the electronic messages. 16. The method of claim 1, wherein the permitting includes the permitting the first user to search the electronic messages of the first user based on a file name extension type associated with attachments to the electronic messages. 17. The method of claim 1, wherein the permitting includes the permitting the first user to search the electronic messages of the first user based on information tagged within the electronic messages. 18. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; and maintaining a repository ofcrowd-sourced tags and corresponding crowd-source tagging rules based on tags and tagging rules provided by users; wherein the associating descriptive tags with the electronic messages of the first user includes associating a crowd-sourced tag to anelectronic message of the first user based on a crowd-source tagging rule and a feature of the electronic message of the first user. 19. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; wherein the analyzing includesrecursively following implied links between senders and recipients of electronic messages to construct an implied social graph of relationships amongst electronic message users, and determining relevance of an electronic message received by the firstuser, with respect to the first user, based on a relationship between a sender of the electronic message and the user within the implied social graph. 20. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; wherein the electronic messagesof the first user include an electronic message sent to the first user and to a second user; wherein the method further includes identifying a task performed with respect to the electronic message sent to the second user; and wherein the performingincludes selectively performing the task with respect to the electronic message sent to the first user based on a relationship between the first and second users within an implied social graph of electronic message users. 21. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; wherein the analyzing includesidentifying a sender of a first electronic message received by the first user and determining relevance of the first electronic message with respect to the first user as a function of at least one of, a relationship between the sender and the first userwithin an implied social graph of electronic message users, a quality of the relationship between the sender and the first user, a syntactic structure of the first electronic message, metadata associated with the first electronic message, a language usedin the first electronic message, a character set used in the first electronic message, an action taken by the first user with respect to a second electronic message for which one or more features are similar to one or more corresponding features of thefirst electronic message, and an action taken by a second user with respect to an electronic message received by the second user for which one or more features are similar to one or more corresponding features of the first electronic message. 22. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the relationship between the sender and the recipient within the implied social graph. 23. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the syntactic structure of the first electronic message. 24. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the metadata associated with the first electronic message. 25. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the language used in the first electronic message. 26. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the character set used in the first electronic message. 27. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the quality of the relationship between the sender and the recipient. 28. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the action taken by the recipient with respect to the second electronic message. 29. The method of claim 21, wherein the determining relevance includes: determining the relevance based at least in part on the action taken by the other recipient with respect to the third electronic message. 30. The method of claim 21, wherein the determining relevance includes determining the relevance based on a combination of a plurality of, the relationship between the sender and the recipient within the implied social graph, the syntacticstructure of the first electronic message, the metadata associated with the first electronic message, the language used in the first electronic message, the character set used in the first electronic message, the quality of the relationship between thesender and the recipient, the action taken by the recipient with respect to the second electronic message, and the action taken by the other recipient with respect to the third electronic message. 31. The method of claim 21, wherein the analyzing further includes: determining a similarity between electronic messages based on one or more of, relationships amongst senders and recipients of the electronic messages, quality of therelationships amongst the senders and the recipients of the electronic messages, syntactic structures of the electronic messages, metadata associated with the electronic messages, languages used in the electronic messages, and character sets used in theelectronic messages. 32. A computer-implemented method, comprising analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; wherein the analyzing includes,parsing information from a first electronic message received by the first user, assigning a meaning to the first electronic message based on the parsed information, identifying a second electronic message received and tagged by a second user, anddefining a tag for the first electronic message based on a combination of the meaning of the first electronic message, the tag assigned to the second electronic message, and a relationship between the first and second users. 33. The method of claim 32, wherein the parsing includes: parsing information from a body of the electronic message and from metadata associated with the electronic message. 34. The method of claim 32, wherein the analyzing further includes: determining the relationship between the first and second recipients with respect to an implied social graph of electronic message users. 35. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages, wherein the performing includesorganizing the electronic messages of the first user into a first organization based on metadata associated with the electronic messages and contents of the electronic messages, and presenting a first body of information associated with the electronicmessages through a graphical user interface in accordance with the first organization. 36. The method of claim 35, wherein the performing further includes: organizing the electronic messages of the first user into a second organization based on the metadata and contents; and presenting a second body of information associatedwith the electronic messages through the graphical user interface in accordance with the second organization. 37. The method of claim 36, wherein the performing further includes: presenting the first and second bodies of information under corresponding first and second tabs of the graphical user interface. 38. A computer-implemented method, comprising: analyzing electronic messages of a first user with respect to one or more features associated with the electronic messages; associating descriptive tags with the electronic messages of the firstuser based on the analyzing; and performing tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages, wherein the performing includes,permitting the first user to submit a query directed to one or more of message bodies, metadata, attachments, and previously assigned tags of the electronic messages of the first user, wherein the query includes a literal component and a reference to anunknown desired component associated with the literal component, identifying a set of the electronic messages that include a reference to the literal component, identifying a subset of the set of the electronic messages that include the desiredcomponent, and returning information from the subset of electronic messages in response to the query. 39. An apparatus, comprising a processor and memory configured to: analyze electronic messages of a first user with respect to one or more features associated with the electronic messages; associate descriptive tags with the electronicmessages of the first user based on analysis results, including to learn electronic message tagging rules based one or more of a statistical machine learning technique and a parser, and associate the descriptive tags with the electronic messages of thefirst user based on features associated with the electronic messages and the learned electronic message tagging rules; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptivetags associated with the respective electronic messages. 40. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages; wherein the computer program further includes instructions to cause the processor to learn electronic message tagging rules based one or more of a statistical machine learning technique and a parser,and associate the descriptive tags with the electronic messages of the first user based on features associated with the electronic messages and the learned electronic message tagging rules. 41. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: perform one more of parse syntactic features associated with the electronic messages, recognize named entities associatedwith the electronic messages, recognize acronyms associated with the electronic messages, detect sentiments expressed within the electronic messages, determine semantic roles associated with the electronic messages, and determine relationships amongstsenders and recipients of the electronic messages with respect to an implied social graph; and associate descriptive tags with the electronic messages based on one or more of the parsed syntactic features, the recognized named entities, the recognizedacronyms, the sentiments, the determined semantic roles, and the determined relationships amongst the senders and recipients of the electronic messages with respect to the implied social graph. 42. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: extract information from electronic messages that are tagged with a first descriptive tag; and present the extractedinformation within a user interface associated with the first descriptive tag. 43. The non-transitory computer readable medium of claim 42, wherein the first descriptive tag, the extracted information, and the user interface correspond to at least one of: online purchases; travel; invitations; newsletters; offers; promotions; scheduled meetings; invoices; online payments; banking/finance; electronic messages awaiting a response from the first user; informational electronic messages that are of high relevance to the first user; and electronic messages thatare of high relevance to the first user and that are awaiting a response from the first user. 44. The non-transitory computer readable medium of claim 42, further including instructions to cause the processor to: associate the first descriptive tag with electronic messages that correspond to a message template; the extracting includesparsing information from the electronic messages that are tagged with the first descriptive tag based on the message template; and the presenting includes presenting the parsed information within the user interface associated with the first descriptivetag. 45. The non-transitory computer readable medium of claim 42, further including instructions to cause the processor to: parse information from the electronic messages that are tagged with the first descriptive tag based on user-provided parsinginstructions. 46. The non-transitory computer readable medium of claim 42, further including instructions to cause the processor to: provide a user-manipulable control within the user interface to retrieve information from a web site based on the extractedinformation; and present the retrieved information within the user interface. 47. The non-transitory computer readable medium of claim 42, further including instructions to cause the processor to: cluster the electronic messages of the first user based on features of the respective electronic messages; associate thefirst descriptive tag to all electronic messages within a cluster of electronic messages; extract information from the electronic messages that are tagged with the first descriptive tag; and present the extracted information within the user interfaceassociated with the first descriptive tag. 48. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: associate a user-identified tag to a user-identified electronic message; identify features of the user-identified electronicmessage; and associate the user-identified tag to other electronic messages that have features similar to the features of the user-identified electronic message. 49. The non-transitory computer readable medium of claim 42, further including instructions to cause the processor to: generate the user interface as a web-page-like interactive user-interface based at least in part on metadata associated withthe electronic message. 50. The non-transitory computer readable medium of claim 49, further including instructions to cause the processor to: aggregate a plurality of the web-page-like interactive user-interfaces in a tab-view. 51. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: host a user-programmable electronic messaging client; and analyze the electronic messages of the first user and perform thetasks within the hosted user-programmable electronic messaging client. 52. The non-transitory computer readable medium of claim 51, further including instructions to cause the processor to: host the user-programmable electronic messaging client as a Python-extensible thick-client electronic messaging system. 53. The non-transitory computer readable medium of claim 51, further including instructions to cause the processor to: host the user-programmable electronic messaging client using one or more of a browser plug-in and an application shell. 54. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: permit the first user to search the electronic messages of the first user based on a file name extension type associated withattachments to the electronic messages and information tagged within the electronic messages. 55. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: permit the first user to search the electronic messages of the first user based on a file name extension type associated withattachments to the electronic messages. 56. The non-transitory computer readable medium of claim 40, further including instructions to cause the processor to: permit the first user to search the electronic messages of the first user based on information tagged within the electronicmessages. 57. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages; wherein the computer program further includes instructions to cause the processor to maintain a repository of crowd-sourced tags and corresponding crowd-source tagging rules based on tags and taggingrules provided by users, and associate a crowd-sourced tag to an electronic message of the first user based on a crowd-source tagging rule and a feature of the electronic message of the first user. 58. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages, including to recursively follow implied links between senders and recipients of electronic messages to construct an implied social graph of relationships amongst electronic message users, and determine relevance of an electronic messagereceived by the first user, with respect to the first user, based on a relationship between a sender of the electronic message and the user within the implied social graph; associate descriptive tags with the electronic messages of the first user basedon analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages. 59. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages; wherein the electronic messages of the first user include an electronic message sent to the first user and to a second user, and wherein the computer program further include instructions to cause theprocessor to, identify a task performed with respect to the electronic message sent to the second user, and selectively perform the task with respect to the electronic message sent to the first user based on a relationship between the first and secondusers within an implied social graph of electronic message users. 60. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages, including to identify a sender of a first electronic message received by the first user and determine relevance of the first electronic message with respect to the first user as a function of at least one of, a relationship between the senderand the first user within an implied social graph of electronic message users, a quality of the relationship between the sender and the first user, a syntactic structure of the first electronic message, metadata associated with the first electronicmessage, a language used in the first electronic message, a character set used in the first electronic message, an action taken by the first user with respect to a second electronic message for which one or more features are similar to one or morecorresponding features of the first electronic message, and an action taken by a second user with respect to an electronic message received by the second user for which one or more features are similar to one or more corresponding features of the firstelectronic message; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptivetags associated with the respective electronic messages. 61. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the relationship between the sender and the recipient within the impliedsocial graph. 62. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the syntactic structure of the first electronic message. 63. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the metadata associated with the first electronic message. 64. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the language used in the first electronic message. 65. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the character set used in the first electronic message. 66. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the quality of the relationship between the sender and the recipient. 67. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the action taken by the recipient with respect to the second electronicmessage. 68. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based at least in part on the action taken by the other recipient with respect to the thirdelectronic message. 69. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: determine the relevance based on a combination of a plurality of, the relationship between the sender and the recipientwithin the implied social graph, the syntactic structure of the first electronic message, the metadata associated with the first electronic message, the language used in the first electronic message, the character set used in the first electronicmessage, the quality of the relationship between the sender and the recipient, the action taken by the recipient with respect to the second electronic message, and the action taken by the other recipient with respect to the third electronic message. 70. The non-transitory computer readable medium of claim 60, further including instructions to cause the processor to: analyze the electronic messages of the first user to determine a similarity between electronic messages based on one or moreof, relationships amongst senders and recipients of the electronic messages, quality of the relationships amongst the senders and the recipients of the electronic messages, syntactic structures of the electronic messages, metadata associated with theelectronic messages, languages used in the electronic messages, and character sets used in the electronic messages. 71. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages; wherein the computer program further includes instructions to cause the processor to, parse information from a first electronic message received by the first user, assign a meaning to the firstelectronic message based on the parsed information, identify a second electronic message received and tagged by a second user, and define a tag for the first electronic message based on a combination of the meaning of the first electronic message, thetag assigned to the second electronic message, and a relationship between the first and second users. 72. The non-transitory computer readable medium of claim 71, further including instructions to cause the processor to: parse information from a body of the electronic message and from metadata associated with the electronic message. 73. The non-transitory computer readable medium of claim 71, further including instructions to cause the processor to: determine the relationship between the first and second recipients with respect to an implied social graph of electronicmessage users. 74. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages, including to organize the electronic messages of the first user into a first organization based on metadata associated with the electronic messages and contents of the electronic messages, and present afirst body of information associated with the electronic messages through a graphical user interface in accordance with the first organization. 75. The non-transitory computer readable medium of claim 74, further including instructions to cause the processor to: organize the electronic messages of the first user into a second organization based on the metadata and contents; andpresent a second body of information associated with the electronic messages through the graphical user interface in accordance with the second organization. 76. The non-transitory computer readable medium of claim 74, further including instructions to cause the processor to: present the first and second bodies of information under corresponding first and second tabs of the graphical user interface. 77. A non-transitory computer readable medium encoded with a computer program including instructions to cause a processor to: analyze electronic messages of a first user with respect to one or more features associated with the electronicmessages; associate descriptive tags with the electronic messages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tagsassociated with the respective electronic messages, including to, permit the first user to submit a query directed to one or more of message bodies, metadata, attachments, and previously assigned tags of the electronic messages of the first user, whereinthe query includes a literal component and a reference to an unknown desired component associated with the literal component, identify a set of the electronic messages that include a reference to the literal component, identify a subset of the set of theelectronic messages that include the desired component, and return information from the subset of electronic messages in response to the query. 78. An apparatus, comprising a processor and memory configured to: analyze electronic messages of a first user with respect to one or more features associated with the electronic messages; associate descriptive tags with the electronicmessages of the first user based on analysis results; and perform tasks with respect to the electronic messages of the first user, on behalf of the first user, based on the descriptive tags associated with the respective electronic messages; whereinthe processor and memory are further configured to maintain a repository of crowd-sourced tags and corresponding crowd-source tagging rules based on tags and tagging rules provided by users, and associate a crowd-sourced tag to an electronic message ofthe first user based on a crowd-source tagging rule and a feature of the electronic message of the first user. Description BACKGROUND Businesses and individuals may establish multiple electronic mail (e-mail) accounts with different hosts or service providers. Some conventional e-mail interface systems are configurable for multiple e-mail accounts. For each account, however, a user must often enter a myriad of information, such as a login name, a domain, incoming and outgoing server names, portnumbers, and security settings. This is time consuming and prone to error, and can be especially challenging to less experienced users. Businesses and individuals may receive relatively large numbers of e-mail messages within a given period of time, and may find it difficult sort through the messages efficiently. Conventional e-mail systems provide relatively limited abilities to pre-sort e-mails. Examples include binary junk or spam filers, and tagging based on user-specified attributes, such as sender e-mail address or key words. While techniques to analyze limited features e-mails may be found in publications, few if any of the techniques appear to have been successfully implemented in an e-mail client, and none teach a user-friendly e-mail client to automaticallydiscover account settings or to organize e-mails in an intuitive way based on a rich variety of features with little or no user input.SUMMARY Disclosed herein are methods and systems to discover electronic message account settings. Also disclosed herein are methods and systems to analyze and organize electronic messages based on one or more of a variety of types of information and features. BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES FIG. 1 is a block diagram of an exemplary computer system configured as an electronic messaging client. FIG. 2 is a block diagram of an electronic messaging environment 200. FIG. 3 is a flowchart of a method 300 of electronic messaging. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears.DETAILED DESCRIPTION For illustrative purposes, features may be disclosed herein with reference to an electronic mail (e-mail) messages and/or with respect to an e-mail messaging client, referred to herein as Arcode Mail, or Arcode, to organize electronic messages. Whereas current e-mail clients present a simple list of messages, Arcode may be implemented to automatically parse and tag messages, and rank messages for relevancy, to provide richer presentation and search capabilities. Features disclosed herein are not, however, limited to e-mails and/or to an e-mail client, and may be implemented with respect to other forms of electronic messaging. One or more features disclosed herein may be implemented alone and/or in various combinations with one another. Tags Arcode may treat message analogously to MP3 music files. Arcode may associate one or more tags with each message, and the tags may include and/or provide semantic information about the message. For example, a shipping confirmation message from Amazon.com might be tagged ""type: online order"" and""vendor: Amazon."" Arcode may determine tags with one or more techniques, which may include a statistical machine learning technique and/or parsers. A statistical machine learning technique may be implemented to cluster similar messages and to select a representative phrase as a tag. Parsers may be targeted to certain kinds of machine-generated messages, such as merchant-specific shipping confirmations. Relevancy Arcode may estimate how important and/or timely a message is to the user or recipient. Whereas spam filtering is binary--a message is spam or it's not--the notion of relevancy in Arcode implies a continuum. Intuitively, a message may be moreor less relevant without being spam. Arcode may be configured to examine a combination of features to ascertain the relevancy of a message. The combination of features may include one or more of: the sender and other recipients; relationship (a) between the sender and therecipient in terms of an ""implied social graph"" connecting parties with whom the sender and/or recipient have sent and/or received e-mail in the past; other message headers; syntactic structure of the message; language of the message and/or characterused in the message; prior action(s) taken by recipient in response to similar messages (e.g., immediately deleted, ignored, forwarded, replied, etc.); and prior action(s) taken by other users in response to similar messages (i.e., crowd-sourced basedactions: how one client uses this information may depend on relation(s) between users derived from the social graph (see Use of Implied Social Graph below). Rendering Arcode may include a hybrid of web browser and email client, such as to permit developers to extend Arcode with arbitrary HTML and/or JavaScript pages that render information pulled from tagged messages. For example, an extension could place atab in client user interface (UI) showing the user's online ordering history: everything they've bought online, and the status of each purchase. The Arcode UI may include manipulable controls. For example, an online orders page may include a package tracking button to check the status via a third party shipping site (e.g., UPS or FedEx websites). As additional examples, tab renderers may be configured with respect to one or more of: online purchases; travel; invitations; newsletters; offers/promotions; upcoming meetings; project XYZ; bills/online payments; banking/finance items; emailsrequiring a response; ""Breaking News"": highly relevant informational messages; and ""Urgent"": highly relevant messages requiring immediate action. A renderer may combine intelligent presentation of information in the user's inbox with collaborative editing of shared web documents. For example, a renderer for ""party invitations"" may track invitations in the user's inbox, and may furtherpermit users to establish a shared event invitation web page that Arcode users could manipulate (such as to accept/decline the invitation, for example), in a ""first-class"" way. Recipients of e-mails linked to such collaborative objects using othere-mail clients may receive ""downgraded"" text-only versions to convey the content in a backward-compatible way. Such users may be prompted to upgrade with an Arcode system. Tabbed Browsing of Renderers An Arcode UI may include a set of user-selectable tabs, analogous to browser tabs used for tabbed browsing. Each tab holds a different view of the person's inbox. The Arcode UI may include a ""classic view"" tab, to present messages as in aconventional email client. The UI may include the classic view tab by default, and may permit a user to select one or more other tabs to include in the UI. Arcode may combine relatively powerful rendering technologies available on the public web and information that exists in the user's private message store. Extensibility; Local Computation Arcode may be configured to allow arbitrary extensions, which may be written in Python. This may permit a developer and/or end user to write new code, such as to parse and tag messages, to influence relevancy estimation, and/or to render taggedlocal content. A Python environment may be hosted within a browser plug-in, so that corresponding computations occur on the user's machine rather than at a remote server farm. Use of Implied Social Graph An ""implied social graph"" is a network of connections implied by recursively following links between people implied by sending and receiving email. This is more than ""degrees of separation"" between a sender and a recipient, and may be performedwith respect to a relatively whole graph and may include stored information about each link along the shortest path between the two. Arcode may be configured to use an implied social graph in one or more ways. An implied social graph may be used in determining message relevancy. For example, if a low degree of separation user has sent mail to a particular person, the relevance of messages from that person may be deemed relatively higher. Likewise,if a similar message has been sent to a very large number of people, as tracked by the global graph data structure, the message is may be deemed relatively low relevancy. An implied social graph may be used to formalize certain intuitive notions about information propagation. For example, information learned from a user about how to tag or estimate the relevance of the user's messages, may be shared with otherneighbors in the social graph on the assumption that people near each other in this graph conceptually have more things in common. Crowd-Sourced Message Tagging Arcode may be configured to implement crowd-source tagging. Machine-generated messages, such as merchant confirmation messages, often follow relatively rigid structures. Arcode may permit end-users or message recipients to tag portions of suchmessages with semantic information using a graphical user interface. For example, a user might highlight ""$150.25"" and tag it ""price."" Users can then contribute taggings to a central repository to be aggregated and shared with others. In this way,Arcode may improve over time via contributions of its users, analogous to Wikipedia. Crowd source tagging may also permit Arcode to adapt to changes in messages, which may not be accommodated with existing taggers. Hand-Written Taggers Arcode may be configured to permit developers to write taggers, such as in Python code. Taggers may be configured to run arbitrary computations, and to do perform tasks, such as accessing network resources. For example, an Amazon tagger couldquery the Amazon web service to determine whether a particular string actually refers to a product for sale on Amazon's site, to help disambiguate the parsing of the message. Automatic Tagging of Similar Messages Arcode may be configured to permit an end user or message recipient to click on a message and select ""automatically tag messages like this one."" Arcode may be further configured to utilize machine learning clustering to identify similarmessages, to present a list of identified messages with checkboxes, and to permit the user to select messages that are similar, as determined by the user. Arcode may be further configured to permit the user to name or select a tag to apply to suchmessages. From then, Arcode will automatically apply the tag to messages matching the learned filter. Incorporation of Disparate Messaging Sources Where Arcode is configured to operate with arbitrary extensions, such as Python extensions, messages from disparate sources, including different and/or new types of messages, may be integrated within a UI. For example, RSS feeds may be broughtinto the system and tagged, similar to e-mail messages. Automatic Discovery of Message Account Settings (e.g., Port and Transport) Arcode may include an account settings discovery process, which may replace multi-page communication-account-setup forms with a form requiring relatively little information such as a user account ID and password. A user account ID may include,for example, a user e-mail address or user account login name. An optional form may permit users with unusual email settings to provide additional information or hints. The Arcode settings discovery process uses the user ID and password to discovermessage settings for the user to send and receive electronic messages, such as e-mails. The information the user puts into the simple form may also be entered via a program run from a terminal console. The Arcode settings discovery process may include one or more of the following processes, which may be performed for each account that is discovered: A) construction of a list of hosts; and, B) connections to each host to determine the user'sincoming and outgoing email provider settings. Construction of a List of Hosts A base domain may be determined by the Arcode settings discovery process by parsing an email address input by the user. For example, bob@mail.aol.com is an example email address that may be parsed into a base username of ""bob"" and a base domainof mail.aol.com. The base domain may be used to check a database of known email providers (e.g. Gmail, Hotmail, AOL), indexed by domain patterns. This database may be maintained within Arcode source code. If the base domain matches a domain pattern,the list of hosts, and sometimes ports and other email settings, from that database item may be added to the settings collection. The settings collection may be used to attempt to connect to the user's incoming and outgoing email server. An exampleprocess of attempting to connect is described below. If the base domain matches an entry in the database of known email providers, and the attempt to connect to the user's incoming and outgoing mail server is successful, the discovery process may be complete. Otherwise, the list of hosts may be constructed by taking the base domain and constructing hostnames using the super-domain of the base domain and also a list of common prefixes. The list of common prefixes (such as imap.domain and smtp.domain)may be pre-determined by the Arcode settings discovery process, such as during design and testing. For example, if the base domain was mail.aol.com, a super-domain may be defined as aol.com. Using common prefixes may result in hostnames such asimap.aol.com and smtp.aol.com. Additionally, a DNS query may be constructed to find any MX records corresponding to the base domain. Hosts in the MX records may be added to the list of hosts. Any optional host hints specified by the user may be added to the list of hosts. The list of hosts may be shortened by consolidating hosts that differ from each other only in numbers. This may help to reduce the number of connection attempts, which may shorten the discovery process. A DNS query may be performed on every host in thelist of hosts. In order to reduce or minimize the amount of time, The discovery process may be configured with respect to a maximum number of queries and/or an overall timeout time. This may reduce or minimize the amount of time of the discovery process. Additionally, or alternatively, during execution of DNS queries, a check may be performed so that each host and each IP is only tried once. It may be desirable to use the shortest possible hostname. The list of hostnames may thus be sorted by length. Connections to Each Host to Determine the User's Incoming and Outgoing Email Provider Settings The Arcode settings discovery process may determine settings for the user's email provider by attempting to connect to a hostname multiple times using the user-provided password and combinations of different usernames, ports, and transports. Possible usernames may include an email address and/or the base username parsed from the email address. For example, if the user-input e-mail address was bob@mail.aol.com, both ""bob"" and bob@mail.aol.com may be added to the list. Any optionaluser-provided username hints may also added to the username list. The optional user-provided username hint may be useful, for example, where the username for the mail server is significantly different than the email address. The list of usernames mayadjusted for an email provider in a list of exceptions created by the Arcode settings discovery process, such as during design and testing. Possible ports and transports may be constructed using a list compiled from internet standards (RFCs) and/or other email provider practices and possible server settings observed during the Arcode settings discovery process design and testing. To this list may be added any optional user-provided port and transports, which may be assigned higher priority on the list. When user-provided ports and transports exist, other ports and transports may be attempted unless prohibited by theemail-specific options. Secure options may be assigned higher priority on the list than insecure options. Setting may be determined using multiple connection attempts in a multi-threaded process. Multi-threading may reduce the time needed to determine or identify a proper connection. Some email providers have safeguards that are triggered byparallel connection attempts. To overcome this, all connection attempts to a given host/port combination may be scheduled or assigned to the same thread. The discovery process may include setting a maximum number of simultaneous connection attempts. This may help to avoid overloading a remote server and/or triggering anti-spamming countermeasures. If a connection attempt is successful using a particular combination of username, port, and transport, connection attempts with respect to any remaining combinations may be halted. This may reduce the amount of time taken during the settingsdiscovery process. If a successful connection to a host is made, additional commands may be attempted over that connection. If the additional commands are successful, the settings for that connection to the user's email provider may be saved for later use. Forexample, when the user subsequently logs in, the settings may be loaded from the saved settings instead of using settings discovery. The setting discovery process may be implemented for both incoming and outgoing providers. Crowd-Sourced Repository of Settings Discovery Results When the Arcode settings discovery process determines the proper settings for a user's email provider, the Arcode client may make a copy of the information and may sanitize the data, such as by removing information in the settings which couldpotentially identify the user. The sanitized copy of the data may be inserted into a crowd-sourced repository which is accessible by other Arcode email client systems. If a user's email provider has been successfully discovered from a previous user session, the Arcode settings discovery process may be omitted. Instead, the settings process can be seeded by the results of the previous successful discoveryprocess which were crowd-sourced into an Arcode settings repository. The use of crowd-sourced e-mail settings may speed the settings discovery process and may use less computing and network resources. Arcode may be configured so that the settingsdiscovery uses the crowd-sourced repository instead of a database of known providers, or in addition to known providers. In a situation where no entry is found in the crowd-sourced repository, the normal settings discovery process may be followed. In asituation where information from the crowd-sourced repository is used but the settings discovery is unsuccessful, the normal settings discovery may be followed. A crowd-sourced repository may include multiple repositories. For a given user group, one of the crowd-sourced repositories may be designated as a primary repository, and another repository may be designated as an alternate repository. Thismay be useful, for example, where characteristics of various user groups (e.g. companies, communities, countries), result in a particular crowd-sourced repository being more relevant and useful. This may also be useful, for example, to located a givenrepository closer to a user group, such as locating a country-based repository proximate to the corresponding country, which may reduce processing time, access times, and/or reliability. Arcode may be configured to bypass crowd-sourcing for the settings discovery process, which may be useful, for example, where Arcode is used in an isolated environment, such as on a secure or isolated network. Arcode may be configurable to permit activation of an email provider only with respect to a particular settings discovery repository. This may be useful, for example, to provide an administrator with control over the email provider settingsand/or to permit an administrator to control which email providers may be used. Such a central repository may provide an administrator with greater control, relative to a situation where email settings are maintained within a Arcode client or in a fileon a user system, such as to update email provider settings information and/or to provide additional enterprise-level security. Additional Optional Features of a Settings Discovery Repository A crowd-sourced settings discovery repository may utilize feedback from unsuccessful results obtained by Arcode settings discovery attempts. For example, if an Arcode settings discovery process attempts to use settings from the Arcoderepository but fails to connect, a maintenance process may take the failure into account and may determine whether to remove the settings for that email provider from the crowd-sourced repository. This may be useful, for example, prevent the Arcodesettings discovery process from spending unnecessary time using the settings from the repository in a later attempt. The determination of whether to remove data after a failure may take into account various factors, such as the number of successful andunsuccessful attempts by the Arcode settings discovery process, the total number of attempts, and/or the amount of time that has passed between successful and/or unsuccessful attempts. This may be useful, for example, to avoid a relatively small numberof unsuccessful attempts from removing email provider settings entries from the repository that have been successfully used for other attempts. A specialized copy of the crowd-sourced settings discovery repository may be used as a utility for system administrators. This may be useful, for example, for administrators who have to deal with relatively large numbers of email servers. Forexample, a specialized copy of a repository may be used for compliance purposes, such in situations where an entity is to account for every email system and the settings of those email servers. In such a situation, the crowd-sourced repository may beconfigured, along with Arcode, to store additional information about individual users. This may be used to help with user email administration. Additional Optional Electronic Message System Features Arcode may be configured to provide one or more of the following features: aggregation of mail across accounts (e.g., a ""meta-inbox""); email summarization: produce better subject lines or summaries ""automatically junk messages like this fromthis sender"" promotion of common text entities into manipulable HTML in the message view; e.g., if we identify an address, we could add a link to map that address (or literally include a map in the HTML message display). delegation/sharing ofpermissions (e.g., an exec assistant could read/write mail on behalf of exec, spouses could share bill information); content-knowledgeable email search (e.g., by multipurpose internet mail extension (MIME) type (video, pdf, word doc, etc.), e.g., Franksphone number or address, attachments sent by Joe); integration of other messaging sources (e.g., RSS/Atom feeds, instant messaging, internet relay chat, XMPP, Jabber, Google Wave); and privacy/confidentiality tools. Privacy/confidentiality tools may be configured to provide warnings about bad CC's (e.g., did you really mean to CC Walt Mossberg at the WSJ, or your officemate Walt Mossberg?). Privacy/confidentiality tools may be configured to provide automatic signing of all outgoing mail (so that Arcode users can be sure of the sender's true identity). Privacy/confidentiality tools may be configured to enforce corporate policy via a per-document DRM-like mechanism (e.g., confidential documents cannot be mailed outside the company). Privacy/confidentiality tools may be configured to provide corporate-wide outgoing mail analysis (e.g., are employees sending bad or secret stuff out?). One or more features disclosed herein may be implemented in hardware, software, firmware, and combinations thereof, including discrete and integrated circuit logic, application specific integrated circuit (ASIC) logic, and microcontrollers, andmay be implemented as part of a domain-specific integrated circuit package, or a combination of integrated circuit packages. The term software, as used herein, refers to a computer program product including a computer readable medium having computerprogram logic stored therein to cause a computer system to perform one or more features and/or combinations of features disclosed herein. FIG. 1 is a block diagram of an example computer system 100 configured as an electronic messaging client. Computer system 100 includes one or more computer instruction processing units, illustrated here as a processor 102, to execute computer program product logic, also known as instructions, code, and software. Computer system 100 includes one or more of memory, cache, registers, and storage (memory/storage) 104, including a computer readable medium having computer program product logic or instructions 106 stored thereon, to cause processor 102 toperform one or more functions in response thereto. Memory/storage 104 further includes data 108 to be used by processor 102 in executing instructions 106, and/or generated by processor 102 in response to execution of instructions 106. In FIG. 1, logic 106 includes client logic 110 to cause processor 102 to process electronic messages, such as described in one or more examples above. Logic 110 may include message tagging and relevancy estimation logic 112 to cause processor 102 to tag messages and to determine message relevancy, such as described in one or more examples above. Logic 112 may include hand-written parsers to tag messages produced from templates. Logic 112 may include logic to identify and tag messages that are similar to one another with a common tag. Logic 112 may include logic to implement client-side crowd-sourced tagging of messages. A server may include corresponding server-side crowd-sourced tagging logic. Logic 112 may include cluster logic to implement one or more clustering techniques to cluster messages. Cluster logic may be configured to provide one or more of syntactic parsing, named entity and acronym recognition, sentiment analysis, andsemantic role analysis. Logic 112 may include logic to utilize an implied social graph, such as described in one or more examples above. Logic 110 may include user interface (UI) logic 114 to cause processor 102 to provide web-page like interactive user interfaces based, at least in part, on message metadata, such as described in one or more examples above. Logic 114 may include logic to aggregate a set of UIs in a tab view, such as described above. Logic 110 may include host logic 116 to cause processor 102 to host a user-programmable messaging client. Host logic 116 may include a browser plug-in and/or application shell to host the messaging client. Host logic 116 may include aPython-extensible thick-client hosting system. Logic 110 may include propagation logic 118 to cause processor 102 to use an implied messaging social graph to propagate information between messaging clients. Logic 118 may include relevancy logic to perform an action with respect to a recipient message, based at least in part on an action taken by another recipient of the message (e.g., if user A immediately deleted message M, then user B may notcare about it either if A is close to B in the social graph). Logic 118 may include logic to share learned tagging behavior amongst clients (e.g., if one user's client has learned how to tag a set of messages, another users's client can benefit from that). Controls may be implemented to protectconfidential information. Logic 110 may include content-aware message search logic 118 to cause processor 102 to search a repository of messages based on content, such as by MIME type. Logic 110 may include auto-discovery logic 120 to cause processor 102 to discover e-mail account settings, such as described in one or more examples above. Logic 110 may include summarization logic 122 to cause processor 102 to generate and display more detailed and/or user-relevant e-mail summaries. Computer system 100 may include a communications infrastructure 140 to communicate amongst components of computer system 100. Computer system 100 may include an input/output controller 142 to communicate with one or more other systems over a communication channel or link, which may include an Internet communication link. One or more features illustrated in, and or described with respect to FIG. 1 may be implemented alone and/or in various combinations with one another. FIG. 2 is a block diagram of an electronic messaging environment 200, including a plurality of communication devices 202 through 218, each configured as an Arcode messaging client, such as described in one or more examples above. Environment 200 may include an Arcode server system 220 to implement one or more features amongst a plurality of devices 202 through 218, such as described in one or more examples above. Devices 202 through 218 may be configured to send and receive messages between one another, and/or between other devices connected through Internet 222. FIG. 3 is a flowchart of a method 300 of electronic messaging. One or more features illustrated in and/or described with respect to FIG. 3 may be implemented alone and/or in various combinations with one another. One or more featuresillustrated in and/or described with respect to FIG. 3 may be implemented within a apparatus, such as computer system, and may be implemented in a distributed fashion over a plurality of systems. At 302, account settings are discovered based on a user account ID and a password. The user account ID may include an e-mail address, such as described in one or more examples above. Discovery of account settings may include parsing a user name and domain from the user account ID at 304, such as described in one or more examples above. Discovery of account settings may include constructing a list of hosts from the parsed domain, and attempting to access the listed hosts at 306, such as described in one or more examples above. Discovery of account settings may include use of one or more repositories at 308, such as described in one or more examples above. At 310, an electronic messaging account may be access using account settings discovered at 302. At 312, electronic messages are analyzed. The analyzing may be performed with respect to historical messages and/or dynamically with respect to incoming and/or outgoing electronic messages. The analyzing may include one or more analysistechniques disclosed herein, a portion of which are shown in FIG. 3 for illustrative purposes. At 314, one or more recipient-specific tasks may be performed based on the analyses performed at 312. The one or more tasks may include message-specific tasks and/or tasks based on a plurality of messages. The one or more tasks may include one or more tasks disclosed herein, a portion of which are shown in FIG. 3 for illustrative purposes. The one or more tasks may include tagging at 316, which may be performed based on one or more analyses performed at 312, such as described in one or more examples above. Tagging at 316 may include crowd-source tagging and/or cluster tagging, such as described in one or more examples above. The one or more tasks may include organizing information in multiple recipient-specific organizations at 318, and displaying the multiple organizations of information in a tabbed browser format at 320, such as described in one or more examplesabove. Methods and systems are disclosed herein with the aid of functional building blocks illustrating the functions, features, and relationships thereof. At least some of the boundaries of these functional building blocks have been arbitrarilydefined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed. While various embodiments are disclosed herein, it should be understood that they have been presented by way of example only, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detailmay be made therein without departing from the spirit and scope of the methods and systems disclosed herein. Thus, the breadth and scope of the claims should not be limited by any of the example embodiments disclosed herein."
9|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=15&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Systems and methods for performing primitive tasks using specialized processors|A primitives library facilitates compiling, linking, and execution of programs that use specialized processors to perform primitive tasks. Data associated with a primitive may be accessed by a specialized-processor-based storage node manager independently of any other processing device.|"1. A computer program interface system comprising: a first storage device comprising a primitive, the primitive comprising a representation of a data-processing task,wherein the representation: (i) is executable, at least in part, by a first field programmable gate array (FPGA) processor of an FPGA module, and (ii) references one or more (A) operands consumed by the task or (B) results produced by the task, theoperands comprising inputs to one or more operations of the task, the results comprising outputs from one or more operations of the task, and the one or more operands or results being stored in a file accessible to the first FPGA processor via anFPGA-based storage node manager independently of any operating system (OS) provided data access function; and an application program interface (API) identifying the primitive, the corresponding task, and the one or more operands or results. 2. The interface system of claim 1, wherein: the FPGA module comprises a second FPGA processor; and the representation of the primitive is executable in part by the first FPGA processor, and is executable in part by the second FPGA processor. 3. The interface system of claim 1, wherein: the first FPGA processor is configured, at least in part, for executing the representation of the task; and the FPGA module comprises: an FPGA processor different from the first FPGA processor andconfigured, at least in part, as the FPGA-based storage node manager; and a second storage device storing the file accessible by the FPGA-based storage node manager. 4. The interface system of claim 3, wherein the second storage device comprises one or more solid state drives (SSDs) for storing the file comprising the one or more operands or results. 5. The interface system of claim 4, wherein the second storage device further comprises a random access memory (RAM). 6. The interface system of claim 4, wherein the one or more SSDs are swappable. 7. The interface system of claim 4, wherein: the task consumes at least a first operand and a second operand; a bitwidth of the first operand is different from a bitwidth of the second operand; and the FPGA-based storage node manager isconfigured to access both the first and second operands of different bitwidths simultaneously. 8. The interface system of claim 3, wherein the first storage device comprises the second storage device. 9. The interface system of claim 1, wherein: the first FPGA processor is configured: (i) in part, for executing the representation of the task, and (ii) in part, as the FPGA-based storage node manager; and the FPGA module comprises a secondstorage device storing the file accessible by the FPGA-based storage node manager. 10. The interface system of claim 1, wherein: the first storage device comprises a plurality of primitives; and the interface system comprises a plurality of APIs, each API identifying a respective primitive from the plurality of primitives. 11. The interface system of claim 1, wherein: the API comprises another file specified in a high-level programming language; and the executable representation of the task is derived from a hardware description language (HDL). 12. The interface system of claim 11, wherein the API implements a binding between the high-level programming language and a C function. 13. The interface system of claim 11, wherein the high-level programming language comprises at least one of C programming language, C++ programming language, PYTHON programming language, JAVA programming language, SCALA programming language,and R programming language. 14. The interface system of claim 1, further comprising an FPGA loader configured to load the executable representation of the task on the first FPGA processor. 15. A method for executing a software program using a field programmable gate array (FPGA) module, the software program comprising an application program interface (API) call to a primitive executable on a FPGA processor, the method comprising:executing the API call on a non-FPGA processor; in response to the execution of the API call, loading on and executing by a first FPGA processor of the FPGA module at least a portion of a primitive comprising a representation of a data-processing task; and accessing by the first FPGA processor a first (A) operand consumed by the task, the first operand comprising an input to an operation of the task or (B) result produced by the task, the first result comprising an output from an operation of the task,wherein the first operand or result: (i) is referenced by the primitive, and (ii) is stored in a file in a first storage device, via a first FPGA-based storage node manager and independently of any operating system (OS) provided data access function. 16. The method of claim 15, wherein the first FPGA processor is also programmed as the first FPGA-based storage node manager. 17. The method of claim 15, wherein: the first FPGA processor and the first FPGA-based storage node manager are different; and the FPGA module comprises the first FPGA-based storage node manager. 18. The method of claim 15, further comprising: storing by the first FPGA processor the first result produced by the task in the first storage device or a second storage device via the first FPGA-based storage node manager; and executing aninstruction by the non-FPGA processor, wherein executing the instruction comprises: accessing the first result from the first storage device or the second storage device, via the FPGA-based storage node manager; and using the first result as an operandof the instruction. 19. The method of claim 15, further comprising: in response to the execution of the API call, loading on and executing by a second FPGA processor of the FPGA module, a portion of the primitive; and accessing by the second FPGA processor asecond operand consumed by the task and stored in a portion of the file in a second storage device, via a second FPGA-based storage node manager and independently of any operating system (OS) provided data access function. 20. A computer program interface system comprising: a first storage device comprising a primitive, the primitive comprising a representation of a task, wherein the representation: (i) is executable, at least in part, by a specialized processingmodule, (ii) is based on, at least in part, an architecture of the specialized module, and (iii) references: (A) an operand consumed by the task or (B) a result produced by the task, the operand comprising an input to an operation of the task, the resultcomprising an output from the operation of the task, and the operand or the result being stored in a file accessible to the specialized processing module via a field programmable gate array (FPGA) based storage node manager independently of any operatingsystem (OS) provided data access function; and an application program interface (API) library comprising an API identifying the primitive, the API being compilable for execution by a processing unit having an architecture that is different from thearchitecture of the specialized processing module, wherein the processing unit does not supply the operand or the result to the specialized processing module. 21. The computer program interface system of claim 20, wherein the specialized processing module comprises at least one of a field programmable gate array (FPGA) processor and a programmable application specific integrated circuit (ASIC). 22. The computer program interface system of claim 20, wherein the specialized processing module comprises: a specialized processor; and a hardware-based storage node manager configured for accessing one or more files stored on a secondstorage device, to permit data exchange between the specialized processor and the second storage device, wherein the hardware-based storage node manager is not part of the specialized processing module and not part of the second storage device. 23. The computer program interface system of claim 22, wherein the specialized processing module comprises the second storage device. 24. The computer program interface system of claim 22, wherein the specialized processing module comprises a memory module directly accessible to the specialized processor independently of the storage node manager. 25. The computer program interface of claim 22, wherein the first storage device comprises the second storage device. Description FIELD OF INVENTION In various embodiments, this disclosure relates generally to application development and execution environments, and, in particular, to environments enabling execution of certain tasks in a software application using specialized processingunits.BACKGROUND In developing a software application, a developer typically writes or provides only a portion of the entire software application. Other portions of the software application are commonly obtained from a third-party library, such as a librarysupplied with a compiler/interpreter, an open-source library, and/or a proprietary library provided by a vendor. The application developer may use an application program interface (API), usually provided by the third party, to access functionalityavailable in the third-party library. A third-party library may be available in source code form and/or object code form. If the source code is available, a compiler/interpreter is typically used to compile the source code written by the developer along with one or more APIs andthe source code of the corresponding functionality. Usually in this case, a binary or an executable is generated for one or more general purpose processors. If the third-party library is available only in the object code form, such library can belinked with the object code obtained by compiling the source code supplied by the application developer, to obtain an executable file. This is generally feasible if the two object code modules are compatible, i.e., if the two object code modules aregenerated for the same types of processors. Some computer systems employ specialized processing modules that may include application specific integrated circuits (ASICs), reconfigurable processing units (e.g., field programmable gate array (FPGA) processing units), etc., for executing thesoftware applications or, more commonly, certain portions thereof. Such specialized processing modules can be faster and/or more efficient than general purpose processors and, as such, after often used to execute computationally intensive tasks and/ortasks that manipulate large amounts of data (e.g., tens or hundreds of megabytes, gigabytes, terabytes, or even larger sizes of data). The tasks to be executed using a specialized processing module may be distinguished from other tasks that are to beexecuted by a general purpose processor using compiler directives. Typically, a general purpose processor (also called central processing unit (CPU)) is in charge of executing the software application. When the CPU determines that a particular task isdesignated to a specialized processor, the CPU requests the specialized processor to execute the task. The CPU also supplies the data required for the execution of the task to the specialized processor, and retrieves results therefrom, for furtherprocessing. The CPU generally reads data from a storage module, writes data thereto, and exchanges data as needed with the specialized processing module. The CPU also generally manages any data exchange between two or more tasks assigned to thespecialized processor(s). Many computers use file management software to access data stored in files stored on storage devices (e.g., hard disc drives (HDDs), solid state drives (SSDs), etc.). The file management software manages requests by applications to open andclose files, create and delete files, read data from files, write data to files, etc. To perform these and other file management operations, the file management software may maintain file system records indicating one or more locations in a storagedevice where a file or parts thereof are stored. When an application requests access to a file or a particular portion thereof, the file management software uses these file system records to determine the address of the requested data on the storagedevice, transmits the appropriate signals to the storage device to obtain the requested data, and passes the requested data to the application. In various computer systems, the file management operations are typically performed by an operating systemrunning on a general-purpose, programmable processing device (e.g., a central processing unit (""CPU"")). Computer systems generally access data from one or more files during the execution of software applications such as applications for audio/video processing, financial transactions, data mining, etc. The CPU that performs the file managementoperations may additionally execute one or more software applications, or a computer system may include additional processors for executing the software applications. As described above, the ASICs and/or reconfigurable (e.g., FPGA-based) processing units generally rely on conventional file management software executed by the CPU for accessing data in files stored on storage devices. Therefore, computersystems that include specialized processors typically include a general purpose CPU which executes an operating system with conventional file management software. Generally in such systems, the CPU uses the conventional file management software toobtain data from a storage device on behalf of a specialized processor and may store the data in a memory that is directly accessible to the specialized processor or may supply the data directly thereto. Likewise, after the specialized processorcomputes a result, the result may be stored in the memory directly accessible to the specialized processor for retrieval by the CPU or may be sent directly to the CPU. The CPU then uses the conventional file management software to store the result in afile stored on the storage device.SUMMARY OF THE INVENTION Although various specialized processing modules can execute certain operations/tasks efficiently, third-party libraries for executing such tasks using specialized processing modules are generally not available. One reason is conventionalcompilers/interpreters that are used to compile/interpret the application developer's code (or a portion thereof) for execution on a general purpose processor cannot compile code such as a third-party library available in source code format for executionby a specialized processor. If a third-party library is provided in the object code form that is suited for the specialized processor, generally such object code cannot be linked with the object code compiled for a general purpose processor. A software developer may leverage a specialized processor's resources by designing and implementing customized modules to perform specified functions on the specialized processor's hardware. Developing such customized modules may require theuse of unfamiliar development tools (e.g., programming languages, compilers, circuit synthesis tools, place-and-route tools, etc.), and/or may require comprehensive knowledge and understanding of the specialized processor's architecture. The investmentof time and effort required to become familiar with new tools and devices can be costly, and therefore can impede the use of specialized processors and/or drive up the cost of software development. The development and distribution of libraries of modules for a specialized processor may reduce the barriers to adoption of the device. If a software developer wishes to use a library module, the developer may do so by integrating the moduleinto the developer's software. Integrating such a module into high-level source code for a general-purpose processor, however, may require the developer to write additional code to control the movement of data back and forth between the specializedprocessor and the general-purpose processor, to configure the specialized processor to implement the task associated with the module, and/or to communicate with the specialized processor. Although such integration efforts may require less use ofunfamiliar development tools and/or less knowledge of the specialized processor's architecture, the investment of time and effort required to integrate a library module for a specialized processor into high-level source code may still impede the use ofthe specialized processor and drive up the cost of software development. Thus, there is a need for improved techniques for integrating specialized processor functionality into high-level source code. The present disclosure describes techniques for exposing data-processing tasks (e.g., ""primitives"") that can be performed by a specialized processor, to software developers. In various embodiments, primitive libraries and APIs to variousprimitives are provided to an application developer. The primitives can be used to configure the specialized processing modules, and may be customized according to the architecture of such modules. Although such primitives cannot be compiled with theapplication developer's source code and also cannot be linked to the object code obtained by compiling the application developer's source code, the APIs to such primitives can be compiled with the application developer's source code, to obtain anexecutable. The APIs themselves do not provide, however, the functionality associated with the primitives and can only identify the primitives and data required and/or supplied by such primitives. Therefore, when the executable of the software applicationincorporating the APIs is run on a computing system that includes both a general purpose processor and the specialized processing module, a configuration mechanism can control loading of the primitives and/or execution thereof using the specializedprocessors, when needed. Moreover, a specialized storage node manager can facilitate data exchange between the specialized processing module and the data storage, without relying on the general purpose processor executing the software application. In some embodiments, these techniques can reduce the investment of time and effort required to invoke the functionality of a specialized processor, thereby facilitating adoption of specialized processors and/or reducing the cost of softwaredevelopment for systems that include specialized processors. This can also result in improved performance of the software applications. Accordingly, in one aspect, a computer program interface system is provided, comprising a storage module and an application program interface (API). The memory module includes a primitive, which includes a representation of a task. The taskrepresentation is executable, at least in part, on a first field programmable gate array (FPGA) processor of an FPGA module. The task representation also references one more data elements corresponding to data associated with the task. The one or moredata elements are stored in a file accessible to the first FPGA processor. The API identifies the primitive, the corresponding task, and the one or more data elements. The file is accessible to the first FPGA processor via an FPGA-based storage nodemanager, independently of any operating system (OS) provided data access function. In some embodiments, the FPGA module includes a second FPGA processor, and the representation of the primitive is executable in part on the first FPGA processor and in part on the second FPGA processor. In some embodiments, the first FPGA processor is configured, at least in part, for executing the representation of the task. The FPGA module may include a second FPGA processor and a storage module. The second FPGA processor may be configured,at least in part, as the FPGA-based storage node manager. The storage module may store the file, which is accessible via the FPGA-based storage node manager. In some embodiments, the storage module includes a random access memory (RAM) and one or more solid state drives (SSDs) for storing the file that includes the one or more data elements. In some embodiments, the one or more SSDs are swappable. In some embodiments, an SSD having a first architecture is swappable with an SSD having a second architecture. In some embodiments, the data associated with the task includes two or more operands corresponding to two or more of the data elements stored in the file. These data elements may have different bit widths. The FPGA-based storage-node managermay be configured to simultaneously access the data elements having differing bit widths. In some embodiments, the first FPGA processor is configured in part for executing the representation of the task and in part as the FPGA-based storage node manager. The FPGA module may include a storage module storing the file accessible viathe FPGA-based storage node manager. In some embodiments, the storage module includes two or more primitives, and the interface system includes, for each of the primitives, an API identifying the primitive. In some embodiments, the API includes a file specified in a high-levelprogramming language, and the executable representation of the task is derived from a hardware description language (HDL). In some embodiments, the API implements a binding between the high-level programming language and a C function. The high-levelprogramming language may be C programming language, C++ programming language, PYTHON.RTM. programming language, JAVA.RTM. programming language, SCALA.RTM. programming language, R programming language, or any other high-level programming languagecapable of binding to a C function. In some embodiments, the interface system includes an FPGA loader configured to load the executable representation of the task on the first FPGA processor. According to an aspect of the present disclosure, a method for executing a software program using a field programmable gate array (FPGA) module is provided. The software program includes an application program interface (API) call to aprimitive. The primitive is executable on an FPGA processor. The method includes executing the API call on a non-FPGA processor. The method further includes, in response to the execution of the API call, loading on and executing by a first FPGAprocessor of the FPGA module at least a portion of a primitive comprising a representation of a task. The method further includes accessing by the first FPGA processor a first data element corresponding to data associated with the task and stored in afile in a first storage module. The first data element is accessed via a first FPGA-based storage node manager and independently of any operating system (OS) provided data access function. In some embodiments, the first FPGA processor is also programmed as the first FPGA-based storage node manager. In some embodiments, the first FPGA processor and the first FPGA-based storage node manager are different, and the FPGA moduleincludes the first FPGA-based storage node manager. In some embodiments, the method includes storing a result element in the first storage module via the first FPGA-based storage node manager. The storing may be initiated by the first FPGA processor. In some embodiments, the method includesexecuting an instruction. The executing may be performed by the non-FPGA processor, and may involve accessing the result element from the first storage module via the FPGA-based storage node manager. In some embodiments, the method includes loading and executing a portion of the primitive on a second FPGA processor of the FPGA module. The loading and executing may be performed in response to the execution of the API call. In someembodiments, the method includes the second FPGA processing accessing a second data element that also corresponds to the data associated with the task. The second data element may be stored in a portion of the file in a second storage module. Thesecond data element may be accessed via a second FPGA-based storage node manager and independently of any operating system (OS) provided data access function. According to an aspect of the present disclosure, a computer program interface system is provided. The system includes a storage module and an application program interface (API) library. The primitive includes a representation of a task. Therepresentation is executable, at least in part, on a specialized processing module. The representation is based, at least in part, on an architecture of the specialized module. The API library includes an API identifying the primitive. The API iscompilable for execution by a processing unit having an architecture that is different from the architecture of the specialized processing module. In some embodiments, the specialized processing module includes a field programmable gate array (FPGA) processor and/or a programmable application specific integrated circuit (ASIC). In some embodiments, the specialized processing module includes a specialized processor and a hardware-based storage node manager. The storage node manager is configured for accessing one or more files stored on a storage module, to permit dataexchange between the specialized processor and the storage module. The hardware-based storage node manager is not part of the specialized processing module and not part of the storage module. In some embodiments, the specialized processing module includes the storage module. In some embodiments, the specialized processing module includes a memory module directly accessible to the specialized processor independently of the storagenode manager. These and other objects, along with advantages and features of the embodiments of the present invention herein disclosed, will become more apparent through reference to the following description, the accompanying drawings, and the claims. Furthermore, it is to be understood that the features of the various embodiments described herein are not mutually exclusive and can exist in various combinations and permutations. As used herein, the term ""substantially"" means.+-.10%, and in someembodiments .+-.5%. BRIEF DESCRIPTION OF THE DRAWINGS In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of theinvention. In the following description, various embodiments of the present invention are described with reference to the following drawings, in which: FIG. 1 is a block diagram of a reconfigurable computing system in accordance with some embodiments; FIG. 2 is an architectural illustration of a reconfigurable computing system in accordance with some embodiments; FIG. 3 schematically illustrates a reconfigurable computing system in accordance with some embodiments; FIG. 4 schematically depicts extent-based information maintained by a hardware-based storage manager for a storage module including two or more storage nodes, according to one embodiment; FIG. 5 is a block diagram of a bus fabric of a reconfigurable computing module in accordance with some embodiments; FIG. 6 is a block diagram of a software development tool chain for a computing system comprising a specialized processor, in accordance with some embodiments; FIG. 7 shows a flowchart of a method for performing a primitive task on a specialized processor, in accordance with some embodiments; and FIG. 8 is a data flow diagram illustrating a method for performing a primitive task on a reconfigurable computing system, in accordance with some embodiments.DETAILED DESCRIPTION A Reconfigurable Computing System Referring to FIG. 1, in some embodiments a reconfigurable computing system 100 includes one or more reconfigurable computing modules (RCMs) 102, memory 106, storage 108 (e.g., a storage module including one or more storage nodes), one or moreprocessors/CPUs 104, and a reconfigurable computing resource manager 110, which includes a storage node manager 132. The reconfigurable computing module(s) may be reconfigurable, at least in part, to perform different operations in hardware. In someembodiments, an RCM may include at least one programmable logic device (e.g., a generic array logic device (GAL), a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), etc.) and/or any other suitable reconfigurable hardware(e.g., logic fabric and/or interconnection fabric that can be reconfigured to perform different operations). Compared to general purpose processors, the RCM(s) can provide relatively high performance and/or may consume less power for specialized tasks. In some embodiments, an RCM and its interconnects may be configured to operate at relatively lowclock frequencies, e.g., at tens or hundreds of MHz and not at a few GHz, and therefore may require relatively less power. The relatively slow clock speed, however, usually does not adversely affect the system performance, in part because, in someembodiments, an RCM and its interconnects exhibit massive bitwise parallelism. For example, the data paths through the RCM may be tens, hundreds, or even thousands of bits wide. Additionally or in the alternative, the RCMs may operate in parallel,i.e., different RCMs may perform the same or different operations in parallel. The combination of high parallelism and low clock speeds can yield a high performance/power ratio. The RCM(s) 102 may be coupled to memory 106. Memory 106 may include volatile, read-write memory. In some embodiments, memory 106 may include, without limitation, random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), and/or anyother suitable type of memory. In some embodiments, memory 106 may be dedicated to RCM(s) 102 (e.g., memory 106 may be accessible to RCM(s) 102, and may be inaccessible to processor(s) 104). The memory 106 may also include several memory modules and aparticular memory module or a particular group of memory modules may be associated with a particular RCM. Different RCM(s) can be configured to perform the same or different tasks and a particular RCM may be configured to perform different tasks atdifferent times during the execution of a data processing procedure involving those tasks. Examples of suitable tasks/subtasks include searching (e.g., fuzzy searching, pipelined sliding window searching, or any other suitable searching task), counting(e.g., determining term frequency in a data set, determining a document's word count, etc.), sorting, data compression, data encryption, image processing, video processing, speech/audio processing, statistical analysis, solution of complex systemsinvolving matrices and tensors, etc. Storage 108 may include non-volatile, read-write memory. In some embodiments, storage 108 includes, without limitation, one or more of flash memory, ferroelectric RAM (F-RAM), magnetic storage (e.g., hard disk), magnetoresistive RAM (MRAM),non-volatile RAM (NVRAM), and/or one or more solid-state drives (SSDs). The storage 108 is generally accessible to the RCM(s) 102 via the reconfigurable computing resource manager 110, and may be accessible to the processor(s) 104, as well. The storage108 may include several (e.g., 2, 4, 6, 10, 12, 16, 20, 32, 48, 64, etc.) components or nodes. A particular storage node or a particular group of storage nodes may be associated with a particular RCM 102 at a certain time and with another RCM 102 at adifferent time. The association between an RCM and one or more storages nodes can change from computation of one task to another and/or between the execution of a pair of subtasks from a set of two or more subtasks associated with a particular task. Insome embodiments, storage 108 or nodes thereof are swappable (e.g., hot swappable). The processor(s) 104 may include one or more processing devices. In some embodiments, processor(s) 104 may include, without limitation, one or more central processing units (CPUs), graphics processing units (GPUs), network processors (NPs),physics processing units (PPUs), microprocessors, microcontrollers, application-specific integrated circuits (ASICs), application-specific instruction-set processors (ASIPs), digital signal processors (DSPs), and/or multicore processors. In someembodiments, the processor(s) 104 may be programmed to execute an operating system (e.g., WINDOWS.RTM. operating system, LINUX.RTM. operating system, OS X operating system). The processor(s) 104 may be programmed to access data from the file(s) storedon the storage 108 through the reconfigurable computing resource manager 110. In some embodiments, the processor(s) 104 may communicate with the RCM(s) 102 through reconfigurable computing resource manager 110 and/or through a bus. In some embodiments,the processor(s) 104 can access the memory 106 and/or the storage nodes of the storage 108. Reconfigurable computing resource manager 110 may be configured to manage one or more resources of reconfigurable computing system 100, including, without limitation, storage 108, RCM(s) 102, input/output (I/O) adapters (not shown), networktransceivers (not shown), and/or routing resources among the components of system 100. In addition, the resource manager 110 includes a storage node manager 132 that can manage the storage 108 and/or the nodes thereof, if the storage 108 includesstorage nodes. To this end, the storage node manager 132 obtains certain selected portions of the file system information (e.g., extent information) from the processor(s) 104 and/or the operating system executing thereon. The selected portions of thefile system information may include a set of starting sectors of file fragments and a corresponding set of contiguous sizes of the file fragments. Using the selected portions of the file system information, the storage node manager 132 can facilitateexchange of data associated with a file between the storage 108 and the memory 106 and/or one or more RCMs 102, without any intervention during the data exchange (i.e., reading data from a file and modifying/writing data to a file), by the processor(s)104 and/or any operating system executing thereon. In some embodiments, the storage node manager 132 may further control the routing of data between the RCM(s) 102 and the storage 108, and/or between the memory 106 and the storage 108. As describedbelow with reference to FIG. 4, the storage node manager may facilitate exchange of data between the storage 108 and the RCM(s) 102, the processor(s) 104, and/or the memory 106. In some embodiments, resource manager 110 includes a reconfigurationcontroller that can configure one or more of the RCMs 102 to perform a specified task. In some embodiments, the reconfiguration controller may initiate reconfiguration of one or more RCMs 102 without the intervention of processor(s) 104 (e.g., inresponse to detecting suitable conditions). In some embodiments, resource manager 110 includes a communications manager configured to manage the I/O resources (not shown) and/or networking resources (not shown) of system 100. In some embodiments, theI/O manager may manage, without limitation, a display adapter, an audio adapter, a network transceiver, and/or any other suitable I/O or network resource. In some embodiments, the RCM(s) 102 may be configured to use the system's communications resourcesthrough the communication manager, without relying on any of the processor(s) 104 and/or the operating system executing thereon. The processor(s) 104 may also access the system's communications resources through the operating system. In some embodiments, the components of a reconfigurable computing system 200 are arranged according to an architecture shown in FIG. 2. The reconfigurable computing system includes four reconfigurable computing modules (RCMs) 202 coupled torespective memories 206 and to a reconfigurable computing resource manager 210. The resource manager 210 is coupled to one or more storage banks 208 (e.g., one, two, four, six, eight, or more than eight storage banks) and to a processor 204, which iscoupled to memory 250 and storage 260. Each RCM 202 includes two reconfigurable computing devices 224 and 226. The reconfigurable computing devices may operate in parallel (e.g., may perform the same operations or different operations in parallel), and/or may be configured toperform bitwise parallel operations. Typically, each reconfigurable computing device includes one or more reconfigurable modules (e.g., FPGA units). A memory 206 may include any suitable type of memory device arranged in any suitable configuration. In some embodiments, a memory 206 may include tens, hundreds, or thousands of gigabytes (GB) of RAM, arranged in any suitable number of memorymodules and/or banks. Each storage bank 208 can include one or more storage nodes of the same or different types, such as conventional disk drives, optical drives, etc. In one embodiment, the storage nodes in a storage bank are solid-state drives (SSDs) such as mSATASSDs or M.2 SSDs. In some embodiments, a storage bank may accommodate swapping (e.g., hot swapping) of SSDs having different form factors. For example, a storage bank may allow replacing one or more mSATA SSDs with one or more M.2 SSDs, and vice versa. For example, in some embodiments, each storage bank may include a carrier board suitable for coupling to one type of SSD, and the swapping of a storage bank's SSDs may be facilitated by swapping a storage bank's carrier board with a different carrierboard suitable for coupling to a different type of SSD. The ability to swap SSDs of different form factors may enhance the computing system's resilience to disruptions in the supply chains of mSATA SSD manufacturers and M.2 SSD manufacturers. Eachstorage node may have any suitable capacity, including, without limitation, capacities ranging from 128 GB through 2 TB, or higher. Storage nodes having smaller capacities, e.g., 64 MB, 128 MB, 1 GB, 2 GB, 4 GB, 8 GB, 32 GB, etc., may also (oralternatively) be included. The storage nodes in one or more storage banks may be logically grouped together to form an FPGA-controlled redundant array of independent drives (RAID). As one example, the system 200 may include eight storage banks, with each storage bankincluding six storage nodes, and the storage banks may be paired to form four RAID devices, such that each RAID device includes twelve storage nodes. In some embodiments, data stored on the storage nodes may be striped, such that data associated with afile or contiguous portions of such file data are stored on different storage nodes. Striping the data in this manner may yield high aggregate bandwidth for accessing/sending such data from/to the storage bank(s) 208. The storage 208 (e.g., the storagenodes) may communicate with resource manager 210 using any suitable interface, including, without limitation, serial ATA (SATA), parallel ATA (PATA), eSATA, SCSI, serial attached SCSI (SAS), IEEE 1394 (FIREWIRE.RTM. communication interface), USB, FibreChannel, INFINIBAND.RTM. communication interface, THUNDERBOLT.RTM. communication interface, and/or Ethernet (e.g., 10 Gigabit Ethernet, 40 Gigabit Ethernet, 100 Gigabit Ethernet, any other Ethernet standard that is available now or may becomeavailable, including, but not limited to, 400 Gigabit Ethernet, etc.). In some embodiments, each storage node includes an SSD, and the storage nodes may be accessed in parallel. In various embodiments, one or more storage banks may include any number (e.g., 2, 4, 5, 6, 8, 10, 12, or more than 12) storage nodes. In some embodiments, the storage banks collectively include up to 48 storage nodes, though more than 48storage nodes are also possible. The number of storage nodes in the storage banks may be selected such that the aggregate input/output (I/O) bandwidth of the storage nodes is approximately equal to the aggregate data-processing bandwidth of thecomputing system's RCMs 202. The number of storage banks and/or the number of nodes in one or more banks may be selected to improve or maximize parallel data exchange between the RCMs 202 and the storage 208 or storage nodes, so that the RCMs 202 can beengaged in data processing up to their processing capacity without letting the I/O become a bottleneck. The processor(s) 204 can access data from one or more files stored on any of the storage banks 208 via a storage node manager 232. This access by the processor is generally independent of the ability of the RCM(s) 202 to efficiently receivedata from a file stored on the storage 208 and/or store data in a file on the storage 208, through a storage node manager 232 without intervention by the processor(s) 204 and/or an OS executing thereon. The processor(s) 204 may communicate with RCM(s)202 through resource manager 210 and/or through a system bus (not shown). Memory 250 and/or storage 260 may be dedicated to processor(s) 204 and may not be accessible to the resource manager 210 or to the RCM(s) 202. Resource manager 210 may be configured to manage one or more resources of the reconfigurable computing system, including, without limitation, storage banks 208, RCMs 202, input/output (I/O) resources (not shown), network resources (not shown),and/or routing among the resources of the system. In various embodiments, the resource manager 210 includes a storage node manager 232, which may be configured to access data from files in storage banks 208 without invoking the data access functions ofan operating system (OS) executing on processor(s) 204. In some embodiments, the storage node manager 232 may control the routing of data between the RCMs 202 and storage banks 208, between the processor(s) 204 and storage banks 208, and/or betweenmemories 206 and storage banks 208. In some embodiments, resource manager 210 may include a reconfiguration controller. The reconfiguration controller may be adapted to control reconfiguration of the RCMs 202. For example, the reconfiguration controller may be adapted to controlreconfiguration of the reconfigurable computing devices (224, 226), and/or to control reconfiguration of the interconnects within or between the reconfigurable computing devices. In some embodiments, such reconfiguration can result in differentprotocols and/or different line rates between the reconfigurable computing devices. In some embodiments, processor 204 may request that the RCMs 202 perform a task by sending a suitable request to the reconfiguration controller, and the reconfigurationcontroller may configure one or more of the RCMs 202 to perform the task. In some embodiments, the reconfiguration controller may configure one or more RCMs 202 to perform multiple tasks. In some embodiments, the reconfiguration controller may initiatereconfiguration of one or more RCMs without the intervention of processor 204. In some embodiments, instead of being separate from the RCMs 202, the reconfiguration controller 210 may be contained within one or more RCMs 202. In some embodiments, resource manager 210 may include a communications manager. The communications manager may be configured to manage the I/O resources (not shown) and/or network resources (not shown) of the reconfigurable computing system. In some embodiments, the RCMs 202 may be configured to use the system's I/O resources and/or network resources through resource manager 210, without the intervention of the processor 204 or its operating system. Embodiments of architecture 200 are not limited by the numbers of components shown in FIG. 2. In some embodiments, a reconfigurable computing system arranged in architecture 200 may include any suitable number of RCMs 202 (e.g., one, two,three, four, or more than four RCMs). In some embodiments, different RCMs may include the same number of reconfigurable computing devices or different numbers of reconfigurable computing devices. An RCM may include, for example, one, two, or more thantwo reconfigurable computing devices. In some embodiments, the system may include any suitable number of storage banks (e.g., eight, fewer than eight, or more than eight), and each storage bank may include any suitable number of storage nodes (e.g.,six, fewer than six, or more than six). In some embodiments, the system may include more than one processor 204. Referring to FIG. 3, in some embodiments a reconfigurable computing system 300 arranged in accordance with architecture 200 may be implemented as a one rack unit (1U) device. The 1U device may be approximately 19 inches wide by 32 inches longby 1.75 inches thick. As can be seen, system 300 includes four reconfigurable computing modules (RCMs) 302 coupled to four corresponding memories 306, eight SSD banks 308, a reconfigurable computing resource manager 310, a motherboard 330, a powersupply 340, storage 352, network transceivers 362-364, and display adapter 366, all of which are arranged on a system board. Each RCM 302 includes two FPGAs 324 and 326, and the memory 306 coupled to each RCM includes up to eight memory modules (e.g., dual in-line memory modules). In some embodiments, the RCMs may include more than eight memory modules. The resourcemanager 310 includes three FPGAs, a PCIe switch, and a serial RapidIO (SRIO) switch. In some embodiments, one or more of the resource manager's components (e.g., the storage node manager, the reconfiguration controller, and/or the communicationsmanager) may be implemented using one or more of the resource manager's FPGAs. For example, a storage node manager 332 may be implemented using one FPGA, as shown in FIG. 3, or more than one FPGA (not shown). In some embodiments, resource manager 310may use either the PCIe switch, or the SRIO switch, or both, to control the data flow between the SSD banks 308 and the RCMs 302, and/or between the SSD banks 308 and the memories 306. In some embodiments, resource manager 310 may use the PCIe switch,the SRIO switch, or both, to communicate with motherboard 330, with network transceivers 362-364, and/or with any other suitable component of system 300. By communicating with network transceivers 362, 364, resource manager 310 may controlcommunications between system 300 and other computing devices (e.g., other reconfigurable computing systems). Any suitable network transceivers 362, 364 may be used, including, without limitation, SFP+, QSFP+, CXP, CFP, CFP2, CFP4, and/orINFINIBAND.RTM. communication interface. In some embodiments, network transceiver 362 may be coupled to a user network for communication with user devices. In some embodiments, network transceiver 364 may be coupled to a cluster network forcommunication with other reconfigurable computing systems. Display adapter 366 may be coupled to any suitable display device, including, without limitation, an LED display, an LCD display, an e-paper display (e.g., an electrophoretic display), and/or a touchscreen display. In some embodiments, resourcemanager 310 may be configured to control display adapter 366, such that data from the RCMs 202, memories 306, and/or SSD banks 308 (including, but not limited to, results of data analysis operations or results of system analysis operations) may bedisplayed by the display device without intervention by motherboard 330 or by any operating system executing thereon. In some embodiments, motherboard 330 may be coupled to display adapter 366, such that the motherboard's processor may control thedisplay adapter. Motherboard 330 may be any commercially available motherboard. A processor may be coupled to the motherboard, and the processor may execute an operating system (e.g., LINUX.RTM. operating system). The processor may have on-chip memory (e.g.,cache memory). In some embodiments, additional off-chip memory may be coupled to motherboard 330. The off-chip memory may be dedicated to the motherboard. In some embodiments, motherboard 330 may be coupled (e.g., by PCIe adapter) to storage 352, tonetwork transceivers 362, 364, and/or to storage banks 308. Power supply 340 may include dual redundant universal AC power supplies of any suitable type (e.g., 100 VAC-240 VAC, 50 Hz-60 Hz). In some embodiments, the system 300 may include one or more fans, e.g., eight hot-swappable fans. Hardware-Based Storage Management Motivation for Hardware-Based Storage Management Many computers use file management software to access data stored in files stored on storage devices (e.g., hard disc drives (HDDs), solid state drives (SSDs), etc.). The file management software manages requests by applications to open andclose files, create and delete files, read data from files, write data to files, etc. To perform these and other file management operations, the file management software may maintain file system records indicating one or more locations in a storagedevice where a file or parts thereof are stored. When an application requests access to a file or a particular portion thereof, the file management software uses these file system records to determine the address of the requested data on the storagedevice, transmits the appropriate signals to the storage device to obtain the requested data, and passes the requested data to the application. In various computer systems, the file management operations are typically performed by an operating systemrunning on a general-purpose, programmable processing device (e.g., a central processing unit (""CPU"")). Computer systems generally access data from one or more files during the execution of software applications such as applications for audio/video processing, financial transactions, data mining, etc. The CPU that performs the file managementoperations may additionally execute one or more software applications, or a computer system may include additional processors for executing the software applications. Some computer systems employ specialized processors such as application specificintegrated circuits (ASICs), reconfigurable processing units (e.g., field programmable gate array (FPGA) processing units), etc., for executing the software applications or certain portions thereof. Such specialized processors can be faster and/or moreefficient than general purpose processors and, as such, are often used to execute computationally intensive tasks and/or tasks that manipulate large amounts of data (e.g., tens or hundreds of megabytes, gigabytes, terabytes, or even larger sizes ofdata). The ASICs and/or reconfigurable (e.g., FPGA-based) processing units generally rely on conventional file management software for accessing data in files stored on storage devices. Therefore, computer systems that include specialized processorstypically include a general purpose CPU which executes an operating system with conventional file management software. Generally in such systems, the CPU uses the conventional file management software to obtain data from a storage device on behalf of aspecialized processor and may store the data in a memory that is directly accessible to the specialized processor or may supply the data directly thereto. Likewise, after the specialized processor computes a result, the result may be stored in thememory directly accessible to the specialized processor for retrieval by the CPU or may be sent directly to the CPU. The CPU then uses the conventional file management software to store the result in a file stored on the storage device. Generally in such computing systems, an operating system (OS) maintains file system data that indicates, for each of one or more files, where the files (or portions thereof) are stored and/or are to be stored on one or more storage devices(e.g., a hard disk, SSD, etc.). A file may be stored in a contiguous or non-contiguous set of storage units, often called blocks, in a single storage device or across several storage devices. The file system data typically includes for each file anidentifier of the storage device where the file or a portion thereof is stored/to be stored, logical block(s) of file, and physical location(s) (i.e., address(es)) of corresponding physical unit(s)/block(s) of the storage device(s). One example of a file system well suited for storing and accessing large files (e.g., files of sizes on the order of tens or hundreds of megabytes, gigabytes, terabytes, or more) is an extent-based file system. Extent-based file systems arewell known and have widespread use in contemporary computing systems. In an extent-based file system, an extent includes one or more contiguous units/blocks of storage. The extent-based file system allocates one or more extents to a file, which tendsto reduce file fragmentation and/or can speed up file access, because an entire large file or at least a significant portion thereof can be stored in a single extent. The allocation of extents often limits the amount of data in the file systemdirectory, as well. When a processor (e.g., a CPU) needs to access one or more data elements from a file and/or is ready to store such data element(s) in a file, the OS generally determines the logical file block(s) corresponding to such data element(s), computesthe physical address(es) corresponding to those logical block(s) using the file system, and accesses and/or stores the data element(s) using the physical address(es). In a computing system that includes one or more specialized processor(s), suchspecialized processor(s) are typically not configured to generate and/or use file system information and/or to access data using such information. Instead, the specialized processors typically rely on a CPU/OS to perform file access operations, i.e.,reading, updating, and/or writing one or more data element(s) from/to a specified file. This may create a performance bottleneck because data processing by the specialized processor(s) becomes dependent on the CPU/OS. One solution is to configure one or more specialized processors to generate and/or use the file system information and/or to provide file access functionality. This, however, can increase the size, complexity, and/or cost of the specializedprocessor(s) and may also decrease their performance. Moreover, if only one or a few specialized processors(s) are configured to provide the file access functionality, the performance bottleneck may still exist because other specialized processor(s)that are not configured to provide the file access functionality may need to depend on the specialized processor(s) that are so configured and or on the CPU/OS. If many or all specialized processor(s) are configured to provide the file accessfunctionality, in addition to likely increase in size, complexity, cost, and/or processing time, the specialized processor(s) may also become burdened with coordinating file access functionality among each other. In many computer systems, the use of conventional, CPU-based file management software to manage a specialized processor's access to storage devices creates a communication bottleneck, which can significantly hamper the overall systemperformance. For example, when conventional, CPU-based file management software is used to manage the flow of data between reconfigurable device(s) and storage, in each processing step, the reconfigurable device(s) may be capable of receiving and/oroutputting data of size greater than the CPU is capable of providing to and/or receiving from the reconfigurable device(s). For example, a reconfigurable device may receive 128 or 256 bits of data per clock cycle while the CPU may provide only 32 or 64bits of data per clock cycle. Thus, the system's performance may be constrained by the bandwidth of communication between the reconfigurable devices and the storage. In addition, the CPU-based file management typically introduces delays in various data transfers. For example, when the reconfigurable device requests data from the CPU, the CPU and the file management software compute the location(s) of therequested data on the storage device. Then, using the computed location(s), the CPU requests the data from the storage device. After the storage device sends the data to the CPU or to a memory, the CPU sends the data to the reconfigurable device or thedevice can access the data from the memory. The delays associated with these communications are often a significant component of the above-described communication bottleneck. In applications in which specialized processors, such as reconfigurable devices, ASICs, etc., are used to process large amounts of data, the specialized processors may read large amounts of data from the storage device, may produce and consumelarge amounts of intermediate data while performing one or more data processing tasks, and/or may store large amounts of intermediate data and/or results in the storage device. This can result in thousands, millions, billions, or even more data accessoperations between the specialized processor and the data storage. As such, even a relatively short delay on the order of several nanoseconds or milliseconds due to the communication bottlenecks described above can result in a significant delay in theexecution of the computationally intensive and/or data intensive tasks. Such delays can therefore make the use of the specialized processors difficult or even impractical, regardless of other benefits offered by such processors. A need for improvement in the bandwidth and/or latency of communication between specialized processors such as reconfigurable FPGA units and storage devices was recognized. An improved data access system can increase the performance of thecomputing systems using the specialized processors, particularly for highly-parallel data processing applications and/or applications processing large amounts of data. In various embodiments, improved data access is facilitated, in part, via aspecialized storage node manager that allows a specialized processor to read/write data from/to a storage device with little reliance on the CPU and the file management software, thereby enhancing the specialized processor's computational throughput andcommunication bandwidth. The specialized processor may rely on the CPU to facilitate file access by providing file allocation data indicative of a location in storage of a file from which the storage node manager may read data and/or to which thestorage node manager may write data. For example, in a system where the operating system uses an extent-based file system, the operating system may provide a portion of extent data to the storage node manager. The provided portion of extent data mayidentify the location in storage of a file (or a portion thereof) that is accessible to the storage node manager for reading and/or writing. After the operating system has provided the data identifying the location of the file, the storage node managermay access the file (e.g., read data from the file and/or write data to the file) one or more times without any further intervention from the operating system. This section describes hardware-based file management techniques for managing access to storage devices. In some embodiments, these hardware-based file management techniques increase the bandwidth and/or decrease the latency of communicationbetween a specialized processor (e.g., a reconfigurable device) and the storage devices, relative to using CPU-based file management software as an intermediary. A hardware-based storage node manager may be implemented using one or more reconfigurabledevices, which can further improve communications between the specialized processor and the storage devices by enabling the storage node manager to adapt to the storage access patterns of the specialized processor. For example, thespecialized-hardware-based manager may adapt the sizes of its internal buffers or the sizes of the pages it fetches from the storage devices based on, e.g., the width of the bus coupling the storage from which the data is accessed to the specializedprocessor, the size of the data elements being accessed by the specialized processor, the rate at which the specialized processor is accessing data elements, the type of processing task (e.g., tasks involving processing of fast streaming data, tasksinvolving batch processing of a large dataset), etc. Hardware-Based Storage Management Referring back to FIGS. 1-3, the resource managers 110, 210, 310 include a hardware-based storage node manager (e.g., the storage node manager 132 shown in FIG. 1, 232 shown in FIG. 2, and 332 shown in FIG. 3). In some embodiments, thehardware-based storage node manager is an FPGA-based storage node manager, i.e., at least a portion of the storage node manager is implemented using one or more FPGAs. For simplicity, the description of hardware-based storage management herein refersprimarily to a computer system having an architecture 200 shown in FIG. 2. It should be understood, however, that the techniques described herein are also applicable to the corresponding components of FIGS. 1 and 3. Also for simplicity, the storagemanagement is described in terms of accessing a file or data associated therewith. Accessing, as used herein, includes not only reading data associated with a file or portions of such data from the storage or one or more storage nodes included in thestorage, but also updating such data or portions thereof on the storage/nodes, and/or writing/storing data or portions thereof to the storage/storage nodes. It is described above that file data access in conventional computing systems using specialized processors is facilitated using a CPU/OS and, to this end, the OS generally provides file management functionality, and generates and maintains filemanagement data. It is also described that using a CPU/OS to access file data generally creates a performance bottleneck. The use of CPU/OS for accessing file data in computing systems such as those described with reference to FIGS. 1-3 presents anadditional challenge. In particular, these systems generally include several storage nodes to provide fast, parallel data access to one or more specialized processors, e.g., RCMs, using, e.g., one or more buses, interfaces, etc. It is described that the number ofstorage modules/banks and the number of storage nodes included in one or more storage modules/banks may be configured according to the processing and/or aggregate I/O capacity of the specialized processors/RCMs (e.g., to maximize utilization thereof). While the OS can be configured to manage and access file data from several storage nodes (such as the storage nodes in an RAID system, for example), if the storage subsystem is customized as described above, the OS may also need to be customized and/oradapted to provide file management for that customized storage subsystem and to access data therefrom. This may be cumbersome or even infeasible. Moreover, the CPU generally cannot access data in parallel from a large number of storage nodes and, in general, must access such data sequentially. Therefore, if a CPU/OS is used for file data access, different specialized processors (e.g.,RCMs) generally cannot access data from the several storage nodes in parallel, via buses/interfaces of selectable widths. As the specialized processors may need to wait for the CPU/OS to access file data sequentially, the collective processing power ofthe specialized processors/RCMs may be underutilized. Various disadvantages of implementing a file system on one or more specialized processors are also described above. In order to maximize the utilization of the RCMs 208, the storage node manager 232 facilitates file data access between storage 208 and the RCMs 202 and/or memory 206 without relying on the CPU 204 and the OS executing thereon during dataread/update/write operations, while employing the OS for file management, so that neither the storage node manager 232 nor any RCM 202 needs to implement a file management system. In addition, the storage node manager 232 accesses only a certain portionof the overall file management data from the OS and manipulates the file management data so that the OS need not be customized substantially according to the structure of the storage 208 in terms of the number of banks and/or nodes. In general, the storage 208 may include ""N.sub.B"" banks and each bank may include ""N.sub.sn"" storage nodes. The N.sub.sn storage nodes may be partitioned into N.sub.G groups, where N.sub.G.gtoreq.1. In some embodiments, each group includes thesame number of storage nodes, denoted N.sub.sn.sup.G, where N.sub.sn=N.sub.G.times.N.sub.sn.sup.G. Data may be accessed (access including reading, updating, and/or writing data, as described above), from each storage node in multiples of a storage unit,e.g., storage node sector. The size in bytes of a storage node sector may be denoted as S.sub.ns. The file data may be striped across the storage nodes of a single group of a single bank, or across the storage nodes of two or more (or all) groups of asingle bank. Additionally or alternatively, the file data may be striped across the storage nodes of some or all of the groups of two or more banks, e.g., across the storages nodes of both groups of one bank and across the storage nodes of only one ofthe two groups of another bank. Only for the sake of simplicity, the description herein considers that the file data is striped across all N.sub.sn storage nodes of a single bank. Thus, file data may be accessed from the storage 208 in multiples ofanother storage unit called storage module sector. The size in bytes of the storage module sector, denoted S.sub.ms, is given by S.sub.ms=N.sub.sn.times.S.sub.ns. In general, N.sub.sn may represent a specified or selected number of storage nodes acrosswhich the file data is to be striped. As an illustrative, but non-limiting example, in one embodiment, the number of storage banks is N.sub.B=4, and the number of groups per bank N.sub.G=2. The number of storage nodes per group N.sub.sn.sup.G=6 and, as such, the number of storagenodes per bank N.sub.sn=12, for a total of 48 storage nodes. The storage node sector size S.sub.ns=512 bytes and, as such, the storage module sector size S.sub.ms=6144 bytes, i.e., 6 Kbytes. In other embodiments, the number of storage banks N.sub.B canbe any number (e.g., 1, 2, 3, 5, 6, 8, 10, 12, 16, 20, 32, or more), and the number of groups per bank N.sub.G can also be any number (e.g., 1, 2, 3, 5, 6, 8, or more). Similarly, the number of storage nodes per group N.sub.sn.sup.G can be any number(e.g., 1, 2, 3, 5, 6, 8, 10, 12, 16, 20, 32, 40, 48, 64, or more) and, as such, each of the number of storage nodes per bank N.sub.sn and the total number of storage nodes can be any number (e.g., 1, 2, 3, 5, 6, 8, 10, 12, 16, 20, 32, 40, 48, 64, ormore). In some embodiments, one or more (or all) of these numbers are powers of two while in other embodiments one or more (or none) of these numbers is a power of two. In various embodiments, the storage node sector size S.sub.ns can be fewer or morethan 512 bytes (e.g., 64, 128, 1 K, 2K, 4K bytes, etc.) and, correspondingly, the storage module sector size S.sub.ms in bytes can be any number (e.g., 2 K, 4K, 8 K, 10 K, 16 K, 32 K or more). In various embodiments, the OS provides the file management functionality according to the storage module sector size S.sub.ms and independently of the particular structure of the storage module in terms of the number of storage banks (N.sub.B),the number of groups per bank (N.sub.G), the number of storage nodes per group (N.sub.sn.sup.G), the number of storage nodes per bank (N.sub.sn), the total number of storage nodes, and/or the storage node sector size (S.sub.ns). Thus, the resourcemanager 210 and/or the storage node manager 232 can configure the storage 208 to include any suitable values of N.sub.B, N.sub.G, N.sub.sn.sup.G, N.sub.sn, the total number of storage nodes, and/or the storage node sector size (S.sub.ns), such that theparallelization of data access between the storage 208 and the RCM(s) 202 and/or memory modules (206), and utilization of the RCM(s) 202 is maximized, without needing substantial reconfiguration or customization of the OS. Regardless of any selectedstorage configuration, the OS views the storage 208 as having a particular storage module sector size S.sub.ms (e.g., 6 Kbytes in the example described above), and generates and maintains the file management data and provides the file managementfunctionality according to S.sub.ms. In typical operation of a system having an architecture depicted in FIG. 2, several files may be stored on and accessed from the storage 208. The sizes of different files can change, i.e., grow or shrink, during the course of operation, and theorder in which the files are accessed during operation can be different than the order in which the files are created, and some files may be deleted. As such, the data of a single file is often not stored in a single contiguous portion on the storage208. Instead, the file data is typically fragmented into several portions and these portions are interleaved with data from one or more other files. Some extent based and other file systems can reduce fragmentation but data fragmentation generallyexists, especially when file sizes are large, such as tens or hundreds of megabytes or gigabytes, or even more. In order to manage and access file data efficiently, an OS may generate and maintain a complex data structure for file management data. Sucha data structure may include pointers, trees, hash tables, etc. The OS may allocate one or more extents to each file, where each extent is a contiguous portion of the storage, and the size of the contiguous portion can be a multiple of the storage module sector size S.sub.ms, or a block size that is relatedto S.sub.ms. The different extents, however, are generally non-contiguous portions of the storage and may have different sizes. Therefore, the OS generally maintains for each extent allocated to a file a starting address of the extent and a length ofthe extent specified in a suitable unit such as the number of bytes, number of blocks, number of sectors, etc. To illustrate, S.sub.ms may be 6 Kbytes (as described in one example above) and two extents may be allocated to a file File_A. In this example, the starting address of the first extent is 6 K (storage node sector 12 in the example of FIG. 4),and the size thereof is 6 Kbytes i.e., a single sector of the storage module. The starting address of the second extent is 30 K (storage module sector 60 in the example of FIG. 4) and the size thereof is 15 Kbytes. As such, the second extent occupiesthree consecutive sectors of the storage module. The first two of these are occupied completely, and the third sector is occupied only partially. The starting addresses and extent sizes are illustrative only. The number of extents can be any numbersuch as 1, 2, 3, 5, 6, 7, 10, 11, etc., and the number of extents associated with different files can be different. For each extent, the OS may also maintain additional information such as a file identifier, logical starting block of the file, etc. In order to access data from a particular file, the storage node manager 232 does not generate or access from the OS the entire data structure that stores the overall file management data that is generated and maintained by the OS. Instead,with reference to FIG. 4, the storage node manager 232 obtains, from the OS, selected extent-related information for the file to be accessed, manipulates the received information as described below, and stores the modified information in an extents table450, for subsequent use during file access. The size of the information corresponding to each extent that is maintained by the OS can be expressed as a parameter ExtentInfoSize. The ExtentInfoSize can be specified in terms of a number of bytes (e.g.,16, 32, 40, 64, 80, 128 bytes, etc.), or in terms of any other suitable unit. In order to store information about all of the extents of a file to be accessed, in some embodiments, the size of the extents table (e.g., the table 450) that is maintained bythe storage node manager 232 can be expressed as the number of extents of a file times ExtentInfoSize. The extents table size can be specified in number of bytes or in any other suitable unit. In some embodiments, the storage node manager 232 stores an address of extents information data (e.g., an address of the extents table 450) corresponding to a file to be accessed (e.g., File_A) in the register R_ExtentInfoAddress 402. Thestorage node manager 232 may also receive from the OS the number of extents allocated to the file to be accessed and ExtentInfoSize for each extent, and store in a register R_ExtentTableSize 404 the size of the extents table (e.g., the table 450) as thenumber of extents of a file times ExtentInfoSize. As such, each row of the table 450 represents a particular extent of the file to be accessed, and all rows have the same size specified by the parameter ExtentInfoSize. As one example, for the fileFile_A the storage node manager 232 would store the address of the extents table 450 in the register R_ExtentInfoAddress 402. If ExtentInfoSize for the extents of the file File_A is 64 bytes, the storage node manager would store 128 bytes (i.e., 2*64bytes) in the register R_ExtentTableSize 404, indicating that the table for File_A (e.g., the table 450) would have two rows 452a, 452b, corresponding to the two extents of the file File_A. Each row of the extents table 450 may include a Length field 454to indicate the size of that extent (e.g., in bytes) that is actually used by the file data, and an Address field 456 identifying the starting address of the extent. Each row 452 may also include one or more additional fields, e.g., a file identifier458, etc. In some embodiments, the storage node manager 232 also obtains from the CPU 204, the OS executing thereon, and/or from one of the RCMs 202, the destination for the file data to be accessed from the storage 208. The destination can be an RCM202, the memory 206 associated therewith, the CPU/OS 204, the memory 250, and/or the storage 260. The destination information may be stored in a register R_Destination 406. Once the information described above is received in various registers 402-406,the CPU/OS 204 and/or the resource manager 210 may set a flag or a register R_GO 408, allowing the storage node manager 232 to perform data access. As described above, the OS generally provides the file management functionality including the extents based allocation according to the storage module sector size S.sub.ms, and independently of the particular structure of the storage module interms of the number of storage banks (N.sub.B), the number of groups per bank (N.sub.G), the number of storage nodes per group (N.sub.sn.sup.G), the number of storage nodes per bank (N.sub.sn), the total number of storage nodes, and/or the storage nodesector size (S.sub.ns). As such, the OS provides the starting address of each extent according to the storage module sector size S.sub.ms. To illustrate, in one example the starting addresses for the two extents of the file File_A as provided by the OSare 6 K and 30 K, respectively, as described above. In general, the OS may provide the starting address of the extent as an address in bytes, as an address in sectors of the storage module, etc. Depending on the particular architecture of the storagemodule in terms of the number of storage nodes, a sector of a storage module as a whole may not correspond to the sectors of individual storage nodes. The storage node manager 232, however, has all the information about the specific configuration of the storage 208 in terms of N.sub.B, N.sub.G, N.sub.sn.sup.G, N.sub.sn, the total number of storage nodes, and/or the storage node sector size(S.sub.ns). As such, in order to access the file data from a selected set of N.sub.ns storage nodes across which the file data are to be striped, the storage node manager 232 coverts the starting address of each extent, whether specified in terms ofbytes or sectors of the storage module as a whole, into a starting address in terms of the sectors of the storage nodes. To illustrate, in the foregoing example where N.sub.sn=12 and the storage node sector size S.sub.ns=512 bytes, the starting address6 K of the first extent is divided by S.sub.ns to obtain the corresponding starting storage nodes sector address as 12. The storage node manager 232 then divides the starting storage nodes sector address by N.sub.sn to obtain a starting sector address in each storage node, and uses this converted sector address for data access to each of the storage nodes. Toillustrate, in the forgoing example, the file data is striped across N.sub.sn storage nodes (e.g., 12 storage nodes 480a-480l). The starting sector address of each storage node is therefore 12/12=1, i.e., the file data represented by the first extentcan be accessed by accessing data from sector address ""1"" of each of the N.sub.sn (e.g., 12) storage nodes 480a-480l. In various embodiments, the starting address(es) of extent(s) may be stored by the storage node manager 232 in the Address field(s) 456of the extents table 450 in bytes, storage module sectors, or storage node sectors. In the foregoing example, the starting addresses of the two extents, as provided by the OS, are expressed in bytes. In some embodiments, the OS may express the starting address of an extent in storage module sectors. In the example above, thestarting addresses of the first and second extents, when expressed as storage module sectors, are 1 and 5, respectively. Likewise, other components that access the storage module via the storage module manager (e.g., the RCMs) may specify the address ofan extent in bytes or in storage module sectors. In some embodiments, a component that provides the address of an extent to the storage module manager may also provide a parameter indicating whether the extent address is specified in bytes or in storagemodule sectors. In some embodiments, the OS may express the extent address in storage module sectors, and the RCMs may express the extent address in bytes. In cases where the OS, an RCM, or some other component is configured to specify an extentaddress in storage module sectors, the reconfigurable computing system may provide that component with data indicating the size of a storage module sector, without necessarily providing that component with data indicating the other parameters of thestorage module. The length in bytes of the file data to be accessed from the first extent is specified by the Length field 454 of the corresponding row 452 in the extents table 450. The storage node manager 232 can divide this length by the storage node sectorsize (S.sub.ns) and further by N.sub.ns (i.e., the number of storage nodes across which the file data are to be striped), to identify the number of sectors to be accessed from each storage node. In the foregoing example, the Length field 454 of thefirst extent is 6 Kbytes and (6 Kbytes/(512 bytes*12)=1). Therefore, the storage node manager 232 would access one sector of each storage node 480a-480l, starting from the sector address ""1."" The data from the sectors 482a-482l of the storage nodes480a-480l can be accessed in parallel. In the foregoing example, the starting address of the second extent of the file File_A, as provided by the OS is 30 K. Therefore, using the values of the parameters S.sub.ns and N.sub.ns, the storage node manager 232 can determine that data fromthe sector 60 is to be accessed and may store the sector address 60 in the Address field 456b. This sector address corresponds to sectors at address ""5"" of each of the N.sub.sn (e.g., 12) storage nodes 480a-480l since 60 divided by 12 is 5. Furthermore, if the length in bytes as specified by the Length field 454b is 15 K, the storage manager 232 would also determine that to access 15 Kbytes of file data, data from three sectors of each storage node, namely 484a-484l, 486a-486l, and488a-488l must be accessed. As this would result in a total of 18 Kbytes of data, the storage manger 232 may discard data accessed from the sectors 488g-488l, after it has been accessed. As such, the data access from the striped storage nodes can beuniform and not dependent on the actual number of bytes to be accessed. The storage node manager 232, however, can truncate the accessed data as necessary, using values of the various parameters described above, and provide only the relevant data to thespecified destination. Thus, in various embodiments, the OS can maintain the overall file system and generate extents based information for each file generally independently of the structure of the data storage. The storage node manager accesses only specific extentsinformation from the OS, manipulates that information according to the structure of the data storage, and then facilitates access to the data of one or more files without needing further involvement of the CPU/OS. Thus, the bottleneck described abovecan be avoided or significantly reduced, without burdening the RCMs. The structure of the storage can be optimized to increase parallel access to the data and/or to increase the performance of the RCMs, without needing substantial correspondingcustomization of the OS. In various embodiments, data of a file is read from the storage and may be provided to one or more RCMs and/or to memory units associated therewith. Alternatively or in addition, the read data may be provided to the CPU(s)/OS. In someembodiments, one or more RCMs and/or CPU(s) may update the data of the file by replacing old data values with new ones. In some embodiments, the RCM(s) and/or the CPU(s) may generate new data and/or may delete existing file data, causing the file sizeto change. In such cases, the OS may update the extents information as necessary, and the storage node manager may use the updated extents information, e.g., to store new data in the file. In some embodiments, an RCM may be configured to store data ina new file. As such, the OS may generate extents information for the new file and the storage node manager may use that extents information, allowing the RCM to store the data in the new file. The data in the newly generated file may be used by one ormore other RCMs and/or by the CPU(s)/OS. Some embodiments include more than one storage node manager. For example, a dedicated storage node manager may be associated with each storage bank. In various embodiments, the operating system running on processor(s) 204 employs an extent-based file system such as e.g., ext2, ext3, ext4, XFS, NTFS, HFS, HFS+, or any other extent-based file system for data stored in the storage 208. Extentsinformation may be accessed by the storage node manager 232 from other extents based files systems, including those that may be developed in the future via a suitable interface. In some embodiments, the extent information is obtained from the OS by thestorage node manager 232 using various standard techniques. In one embodiment, a fiemap( ) system call is used, which both the operating system and extent-based file system support. The fiemap( ) system call is an I/O control (ioctl) method allowing aprogram running in user space to retrieve file extent mappings. The storage node manager 232 as described herein is generally light weight, i.e., the storage node manager 232 may not perform a number of functions of a typical file manager, or of the overall memory management subsystem of an operating system. Instead, the storage node manager 232 uses extent lists represented as starting sectors and contiguous sizes to read and write data without operating system interference, which allows for rapid analysis of the data and rapid writes of results of thatanalysis back to the storage 208. In this way, in various embodiments, the storage node manager 232 can facilitate fast and efficient exchange of data between one or more specialized processors (e.g., RCMs 202) and one or more storage devices/nodesincluded in the storage 208. Returning to FIG. 3, the hardware-based storage node manager 332 includes provisions for reading data from and writing data to one or more storage devices/nodes. Storage node manager 332 may use any interface suitable for communicating with thecomputing system's storage node(s), including, without limitation, serial ATA (SATA), parallel ATA (PATA), eSATA, SCSI, serial attached SCSI (SAS), IEEE 1394 (FIREWIRE.RTM. communication interface), USB, Fibre Channel, INFINIBAND.RTM. communicationinterface, THUNDERBOLT.RTM. communication interface, and/or Ethernet (e.g., 10 Gigabit Ethernet, 40 Gigabit Ethernet, 100 Gigabit Ethernet, etc.). When the address of a storage access request has been determined, the storage node manager communicatesthe appropriate request (e.g., a read request or a write request) and the corresponding data (e.g., the address for a read request, or the address and the data to be stored for a write request) to the storage node(s). In one embodiment, large-scale data striping (similar to RAID 0 architecture) for both read and write access is possible independent of operating system and processor(s) (e.g., the processor(s) 204 shown in FIG. 2), whereby the OS specifiedstarting addresses in the extent lists and their respective contiguous sizes are provided to, and modified and managed by the hardware storage node manager 332, as described above with reference to FIG. 2. As such, the same starting sector can be usedacross a large number of storage devices/nodes in each storage module/bank (e.g., 308a-h), and the requested size can be split amongst the devices/node in each storage module/bank. Specifically, in various embodiments, the storage node manager performsmodulo arithmetic given the size of the storage bank and the extent list size(s) as provided by the processor(s)/OS, to access locations across the storage bank for reading or writing the specified data elements. This implementation differs from typical proprietary RAID 0 architectures at least because these embodiments utilize derivative file extent information generated by the storage node manager using the extent-based file system managed by the OS. The derived information can be utilized across any selected number of storage nodes, independent of any operating system and CPU, as described above with reference to FIG. 2. This allows the processor(s) and their operating system(s) to interact withthe storage node manager precisely the same way, independent of how many storage devices/nodes are included the storage module(s)/bank(s), or the total number of storage devices/nodes. In some embodiments, the computing system may adapt the hardware-based storage node manager 332 based on any suitable information, including, without limitation, the characteristics of the processing devices served by the storage node managerand/or the characteristics of those processing devices' storage access requests. In some embodiments, characteristics of a processing device on which adaptations are based may include, without limitation, the width of the bus coupling the storage nodemanager to a processing device. In some embodiments, characteristics of a processing device's storage access requests on which adaptations are based may include, without limitation, the size of the data elements being accessed by the processing deviceand/or the rate at which the processing device is accessing data elements. Adaptation of the storage node manager may, in some embodiments, improve the performance of the computing system. Referring to FIG. 5, in some embodiments an RCM includes an RCM fabric 500, which communicatively couples the RCM's processing resources to the rest of the RCM, and thereby, to the system's resource manager and/or storage. The RCM fabric 500may include an RCM transceiver fabric 510, an RCM crosspoint switch 520, an RCM control interface 530, an RCM data routing module 540, an internal reconfiguration controller 550, a data interconnect 542, and a control interconnect 532. The datainterconnect 542 may be coupled to one or more reconfigurable processing partitions 560 (e.g., four partitions 560a-560d). In some embodiments, RCM fabric 500 is implemented using one of the two RCM's reconfigurable computing devices (224, 226 shown in FIG. 2). In other embodiments, the components of RCM fabric 500 may be divided between the reconfigurablecomputing devices in any suitable way. For example, reconfigurable computing device 224 may implement the reconfigurable processing partitions 560, and reconfigurable computing device 226 may implement the remainder of the RCM fabric 500 (e.g., thetransceiver fabric 510, crosspoint switch 520, control interface 530, data routing module 540, internal reconfiguration controller 550, data interconnect 542, and control interconnect 532). RCM transceiver fabric 510 communicatively couples the two RCM FPGAs together via a number of I/O lanes 502. The I/O lanes may be implemented using any suitable I/O technology, including, without limitation, high-speed (e.g., 10 Gb/s) serialI/O. The I/O lanes may carry any suitable information, including, without limitation, operand data (e.g., operands for operations to be performed by the RCM), result data (e.g., results of operations performed by the RCM), and/or control data (e.g.,instructions for reconfiguring the RCM and/or data relating to reconfiguration of the RCM). In some embodiments, transceiver fabric 510 may switch signals between the relatively high-frequency, low bit-width I/O lanes 502 and one or more relativelylow-frequency, high bit-width buses 512 (e.g., an operand/result data bus 512a and a control data bus 512b). In some embodiments, the aggregate bit-width of the buses 512 may be hundreds or thousands of bits. In some embodiments, the frequencies of thebuses 512 may be adjustable between tens of MHz and hundreds of MHz. The RCM buses 512 may be coupled between RCM transceiver fabric 510 and RCM crosspoint switch 520. In some embodiments, RCM crosspoint switch 520 may route incoming data from RCM transceiver fabric 510 to RCM control interface 530 (e.g., vialocal bus 522, interrupt bus 524, and/or message bus 526), to RCM data routing module 540 (e.g., via operand/result data bus 528), and/or to internal reconfiguration controller 550 (e.g., via control data bus 529), as appropriate. In some embodiments,RCM crosspoint switch 520 may route incoming data from RCM control interface 530 and/or RCM data routing module 540 to RCM transceiver fabric 510. In some embodiments, the maximum bandwidth between RCM crosspoint switch 520 and the downstream components530-550 may be greater than the maximum rate of data throughput between system storage and transceiver fabric 510. In this way, bus fabric 500 may be configured to accommodate future increases in the rate of data throughput between system storage andRCM transceiver fabric 510 via I/O lanes 502 without requiring modifications to the RCM architecture. RCM data routing module 540 may be configured to route incoming operand data from the RCM crosspoint 520 to one or more of the RCM's reconfigurable partitions 560, and/or to route incoming result data from reconfigurable partitions 560 to RCMcrosspoint 520, for further transmission of the data (e.g., to a storage device, another RCM, or another processing device) via I/O lanes 502. In some embodiments, the data interconnect 542 coupling the RCM routing module 540 to the reconfigurablepartitions 560 may be hundreds or thousands of bits wide. In some embodiments, the RCM bus fabric 500 includes an RCM data routing module 540 for routing data between the RCM's partitions 560 (e.g., between one partition and another partition, or between a partition and another component of thereconfigurable computing system). In such embodiments, the RCM bus fabric 500 also includes a data interconnect 542 coupling the RCM's partitions 560 to the RCM's data routing module 540. Data interconnect 542 may be configurable to operate in variousmodes, including, without limitation, a parallel interconnect mode, a sequential interconnect mode, and/or a conditional interconnect mode. In the parallel interconnect mode, data interconnect 542 may route the same data to two or more partitions 560 inparallel, thereby allowing those partitions 560 to operate on the data in parallel. In the sequential interconnect mode, data interconnect 542 may route input data provided by the crosspoint switch to a first partition, route result data produced by thefirst partition to a second partition, and so on until the result data produced by the last partition is routed back to the crosspoint switch 520, thereby allowing the partitions 560 to operate on a data stream in sequence (e.g., in pipelined fashion). In the conditional interconnect mode, data interconnect 542 may determine the partition to which data is routed based on data (e.g., data received from the crosspoint switch or data provided by the partitions), thereby allowing data interconnect 542 toimplement control flow logic (e.g., if-then-else) in hardware. In some embodiments, each RCM includes its own RCM bus fabric 500, and each of the RCM bus fabrics is connected to the reconfigurable computing system's resource manager (110, 210, 310, shown in FIGS. 1, 2, and 3, respectively). Thus, thereconfigurable computing system may include a multi-RCM bus fabric coupling reconfigurable partitions 560 on different RCMs to each other and to the system's storage (108, 208, 308). RCM control interface 530 may determine the mode of the datainterconnect by providing control signals on control interconnect 532 in response to control data received from the crosspoint switch. The reconfiguration controller 550 may be configured to independently reconfigure the partitions. In anotherembodiment, one of the two RCM FPGA devices (for example, in reference to RCM 202a, either 224a or 226a) may contain bus fabric 500, and the other RCM FPGA may act solely as a data switching and routing engine to the reconfigurable system's resourcemanager and the local RAM resources of the RCM (302a, 306a, and so on). In that case, the two RCM FPGAs become functionally distinguishable, where one is dedicated to primitive processing, and the other for managing off-RCM data switching and routing. This can allow for improved processing performance on the primitive FPGA. In some embodiments, an FPGA unit is a single partition 560 of a single FPGA fabric 500 implemented by a single FPGA device/chip 224 or 226 shown in FIG. 2. In some embodiments, an FPGA unit can be a combination of two or more partitions 560 ofa single FPGA fabric 500. In some embodiments, an FPGA unit includes all of the partitions 560 of a single FPGA fabric, i.e., each device 224 (or 226) is an FPGA unit. Regardless of how an FPGA unit is configured in a particular implementation, ingeneral, any FPGA unit can be configured to receive data from and send data to any other FPGA unit, directly and/or via associated memory module(s) and/or storage, using one or more of the RCM control interface(s) 530, the RCM data routing module(s) 540,crosspoint switch(es) 520, the transceiver fabric(s) 510, and one or more of the busses 502, 512, 522, 524, 526, 528, 529, 532, and/or 542 of one or more FPGA fabric(s) 500. Specifically, if an FPGA unit is a single partition 560 of an FPGA fabric 500 implemented by a device 224a or 226a (shown in FIG. 2), that FPGA unit can exchange data, directly and/or via the associated memory module(s)/storage, with any otherpartition(s) 560 (i.e., FPGA unit(s)) of the same FPGA fabric 500 implemented by the device 224a or 226a, and/or with any partition(s) 560 (i.e., FPGA unit(s)) of a different FPGA fabric 500 implemented by a different device, e.g., any of 224b-d and/or226b-d. Similarly, if an FPGA unit is a group of partitions 560 of an FPGA fabric 500 implemented by a device 224a or 226a, that FPGA unit can exchange data, directly and/or via the associated memory module(s)/storage, with any other group(s) ofpartitions 560 (i.e., FPGA unit(s)) of the same FPGA fabric 500 implemented by the device 224a or 226a, and/or with any other group(s) of partitions 560 (i.e., FPGA unit(s)) of a different FPGA fabric 500 implemented by a different device, e.g., any of224b-d and/or 226b-d. It should be understood that even though FIG. 2 depicts a total of four RCMs 202 and two devices 224, 226 per RCM, and FIG. 5 depicts four partitions 560 per FPGA fabric 500, these numbers are illustrative only. In general, the total number ofRCMs can be any number, e.g., from 1-12 or more, the number of devices per RCM can be any number, e.g., from 1-6 or more, and the number of partitions per device/FPGA fabric can also be any number, e.g., 1-8, or more. Also, different RCMs can includedifferent numbers of devices and different devices/fabrics can include different numbers of partitions. An FPGA unit can be a single partition, a group of partitions, a single device, or a group of devices, and different FPGA units can be different interms of the numbers of partitions included therein. Techniques for Performing Primitive Tasks on Specialized Processors Primitives and Primitive Libraries In some embodiments, one or more primitives may be provided for a computing system that includes a specialized processor (e.g., a reconfigurable computing system having one or more RCMs). Any suitable data-processing task may be implemented asa primitive, including, without limitation, searching (e.g., exact match searching or fuzzy searching), counting (e.g., determining term frequency), sorting, data compression, data encryption, image processing, video processing, speech/audio processing,statistical analysis, and/or solution of complex systems involving matrices and tensors, etc. Specialized processors may include, without limitation, reconfigurable computing devices, graphics processing units (GPUs), network processors (NPs), physicsprocessing units (PPUs), co-processors, application-specific integrated circuits (ASICs), application-specific instruction-set processors (ASIPs), digital signal processors (DSPs), and/or any other suitable processing device configured to perform one ormore particular tasks or task types. A primitive, in general, includes a representation of a task that can be executed by a specialized processor. To this end, the representation includes instructions/data for adapting or configuring the specialized processor to perform theprimitive task. Suitable representations of primitive tasks may include, without limitation, a configuration file for reconfiguring a reconfigurable computing device to perform the primitive task, and/or control parameters suitable for adapting aspecialized processor to perform the primitive task. In some embodiments, a configuration file for reconfiguring a reconfigurable computing device is derived from a hardware description (e.g., a register-transfer level description, a gate-leveldescription, etc.) of the task. The hardware description typically describes circuitry for implementing the task and/or control parameters and/or instructions for adapting a specialized processor to perform a particular task. Such hardware descriptioncan be provided using any suitable language, including, without limitation, a hardware description language (HDL) (e.g., VHDL or Verilog) and/or System C, etc. In various embodiments, a primitive's representation may reference a data element that corresponds to data associated with the primitive task, and the data may be stored in a storage device. In some embodiments, the storage device may beaccessible to the specialized processor and to a general-purpose processing device, as well. In various embodiments, the storage device is accessible to the specialized processor via a specialized-processor-based storage node manager (e.g.,hardware-based storage node manager 132, 232, or 332 as illustrated in FIGS. 1-3), without invoking the data access functions of an operating system. The specialized-processor-based storage node manager may, however, access the data via a memorycontroller or other suitable processing device that is integrated with the storage node manager and/or is integrated with the storage device on which the data is stored and/or controls the operation of such a storage device. In some embodiments, execution of a primitive by a specialized processor may be initiated by a specialized configuration module, a resource manager, or by another processing device (e.g., a general-purpose processing device). The otherprocessing device may not, in some embodiments, manage (e.g., control or direct) the primitive's execution after the initiation thereof. In some embodiments, a specialized processor executing a primitive may use different bit widths for different types of operands. For example, a specialized processor may use a first number of bits for storing, transmitting, and/or processingoperands of a first type, and use a second number of bits for storing, transmitting, and/or processing operands of a second type. By doing so, the specialized processor may improve storage efficiency, bus utilization, and/or data processing efficiencyrelative to processing devices in which all data is stored, transmitted, and/or processed using the same bit width (e.g., 64 bits). In some embodiments, a primitives library is provided for performing one or more primitive tasks using specialized processor(s). Application program interfaces (APIs), to the primitives in a primitives library may expose one or more interfaceelements corresponding to respective primitives. In some embodiments, the interface element corresponding to a primitive may include a software construct (e.g., a high-level language construct). A software developer may include such a softwareconstruct in source code (e.g., high-level source code) of an application to configure a specialized processor to perform a corresponding primitive and/or to initiate execution of the corresponding primitive on the specialized processor. Any suitablesoftware construct may be used to interface to a primitive, including, without limitation, a function call and/or any other suitable high-level language construct. The APIs can be provided in an API library. In some embodiments, the API for a primitive may identify the primitive (e.g., a unique identifier associated with the primitive, or the address of the primitive in storage or in a file), the task performed by the primitive (e.g., searching),and/or one or more data elements accessed by the primitive task. In some embodiments, the use of a primitives library may facilitate invocation of primitives in high-level source code, compilation of high-level source code that invokes primitives, and/or linking of software that invokes primitives tocorresponding representations of primitive tasks. In some embodiments, a primitive may be invoked in source code by calling a corresponding function exposed by the primitives library API. During compilation, the function call may be compiled in thesame manner as any other function call. During linking, the function call may be linked with a task representation suitable for performing the corresponding primitive task on a specialized processor. In some embodiments, the primitives library API may encapsulate aspects of primitives, such that these aspects are partially or completely hidden from the software developer. For example, the primitives library API may encapsulate communicationbetween a general-purpose processing device and a specialized processor, the process of adapting (e.g., reconfiguring) a specialized processor to perform a primitive task, and/or the primitive task's implementation on the specialized processor. Encapsulating aspects of primitives may facilitate development of software that uses primitives by reducing the burden on the software developer. For example, a software developer invoking a primitive through the primitives library API may beunaware that the primitive task is performed by a specialized processor, or unaware of the architecture of the specialized processor performing the primitive task. Also, encapsulating a primitive's implementation may facilitate the development ofprimitives. In some embodiments, a primitive developer may change the implementation of a primitive (e.g., to make better use of a specialized processor's resources) and/or add different implementations of a primitive (e.g., for different specializedprocessors), and the new primitive implementations may be linked to existing source code without requiring modifications of the existing source code. A primitives library API may be specified in any suitable programming language, including, without limitation, C programming language, C++ programming language, PYTHON.RTM. programming language, SCALA.RTM. programming language, R programminglanguage, or JAVA.RTM. programming language. When a primitives library is implemented in C or C++, source code developed in C or C++ may access the primitives library using native features of the language, and source code developed in many otherhigh-level languages (e.g., PYTHON.RTM. programming language, SCALA.RTM. programming language, R programming language, or JAVA.RTM. programming language) may seamlessly bind to the primitives library. Thus, implementing a primitives library in C orC++ may make the primitives library widely accessible to software developers using a wide variety of programming languages and development tool chains. It should be understood however, that in general a primitive API encapsulates an implementation of a primitive, which can be customized according to a computing system having one or more specialized processors. The primitive API may bespecified in any suitable language, referred to as primitive API language. A developer may invoke that primitive via the corresponding API in a system specification provided in a system-specification language, so that the primitive implementation isincorporated into the specified system. The systems-specification language can be the same as the primitive API language, or can be a different language if a compiler for the system-specification language permits invocation of APIs specified in theselected primitive API language. If such a compiler is available, any presently used or future developed programming/scripting language can be selected as the primitive API language, system-specification language, or both. The remainder of this section of the present disclosure describes tool chains for developing software for specialized-processor-equipped computing systems, and techniques for performing primitive tasks on specialized processors. A Software Development Tool Chain FIG. 6 shows a process, also called a tool chain 600 for developing software for a computing system having one or more specialized processors. In various embodiments, the software development tool chain 600 includes a primitives library 622 anda library of primitives APIs 620 for interfacing to the primitives in the library 622. An application developer can write source code for a particular software application that requires performing one or more specialized tasks. For example, a data mining operation may require counting the number of unique values in a large dataset, or a vulnerability detection application may need to determine if a certain signature is present in any of several large files. Typically, the application developer develops an algorithm to perform such tasks and then implements the algorithm bywriting code therefor, which, when compiled, is typically executed by one or more general-purpose processors of a computing system. Specialized processors, however, can be customized to perform various tasks (also called primitives or primitive tasks), including complex tasks and/or tasks that require processing large quantities of data. The primitives library 622 generallyincludes a collection of representation of such tasks, where the representation can adapt or configure a specialized processor to perform that primitive. Via the library of primitives APIs 620, the application developer can simply invoke one or moresuitable primitives APIs in the source code 612, thereby minimizing the application developer's burden of having to implement several computation and/or data intensive tasks. Moreover, while an application developer may know that the computing system executing the application includes one or more specialized processors, typically, the application developer lacks knowledge of the architecture of the specializedprocessor(s), e.g., the number of specialized processor(s), whether they have access to shared, local, and/or dedicated memory and/or access to other specialized processors, etc. Therefore, the application developer usually cannot implement thetask/primitive to take full advantage of the available specialized processor(s). The representation of a primitive in the primitive library 622, however, is based on the knowledge of the architecture of the specialized processor(s) and, hence, executionof the primitive using the specialized processor(s) can improve overall system performance. Therefore, by invoking in the source code, via the library of primitives APIs 620, one or more primitives provided in the primitives library 622 the applicationdeveloper can improve performance of the application. A compiler/linker 614 can compile and link source code 612 that includes one or more interfaces in the library of primitive APIs, to generate executable software 616 that invokes one or more specialized-processor-based primitives. Tool chain600 may include a software loader 618 for loading software 616 onto processing device(s) 604, and a primitive loader 624 for adapting a specialized processor 602 to implement the primitives invoked by software 616. Aspects of tool chain 600 aredescribed in further detail below. The source code 612 that may invoke one or more specialized-processor-based primitives may conform to any suitable programming paradigm, including, without limitation, the object-oriented, procedural, functional, and/or imperative paradigms. Insome embodiments, source code 612 may include code expressed in any suitable programming language, including, without limitation, C programming language, C++ programming language, Objective C programming language, C# programming language, JAVA.RTM. programming language, JAVASCRIPT.RTM. programming language, PYTHON.RTM. programming language, PHP programming language, SQL programming language, SCALA.RTM. programming language, R programming language, and/or PERL.RTM. programming language, etc. Thelibrary of primitive APIs may provide APIs in various programming languages so that a suitable API can be used in the source code 612. The API includes a reference to the corresponding primitive in the primitives library 622 and, during execution of the compiled API by the processor(s) 604, the processor(s) 604 or another controller can initiate the execution of the primitiveby one or more specialized processor(s) (also called accelerator device(s)) 602. The compiler/linker 614 may include a conventional compiler/linker, including, without limitation, GNU's gcc or Intel's icc. The compiler/linker 614 can compile and link an invocation of an API associated with a primitive provided in the primitives library 622 in a similar manner in which function calls and/or other library calls are compiled and linked. There areimportant differences, however, between a function (or other code construct/component) from a conventional library and a primitive from a primitives library. Specifically, in the case of the former, typically the processor executing other portions ofthe software also executes the function/component from the conventional library. Also, the function/component from the conventional library is usually customized/optimized for a general purpose processor executing the entire software. The primitivesfrom a primitives library, however, are not executed by a general purpose processor executing other portions of the software application using the primitives. Moreover, the primitives are not customized/optimized for such processors. Instead, theprimitives are customized for one or more special purpose processors that may provide only a limited functionality corresponding to one or more primitives in the primitives library 622. To illustrate various steps of the process/tool chain 600 described above, the source code 612 may invoke a function ""PrimitiveSearch(&Data;, &Target;)"", where ""PrimitiveSearch(string* Data, string* Target)"" is an interface, exposed by the libraryof primitives APIs 620, to a search primitive. Compiler/linker 614 (e.g., gcc) may compile the invocation of ""PrimitiveSearch"" and link it to facilitate execution of a search primitive provided in the primitives library 622. The search primitive mayinclude a representation of a search task suitable for performing the search task on specialized processor(s) 602. To this end, the search primitive includes code for adapting the specialized processor(s) 602 to implement the search primitive (e.g.,code for configuring the specialized processor(s) to implement the representation of the search task). As described above, the API interface for a primitive may identify the primitive, the task performed by the primitive, and/or one or more data elements accessed by the primitive. The API interface may identify the primitive using any suitabletechnique. In some embodiments, the identity of the primitive may be derived based on the identifier of the API interface (e.g., ""PrimitiveSearch"" in the example of the preceding paragraph) and/or the data types of the parameters to the API interface(e.g., string* and string* in the preceding example). In other words, each primitives library API interface may have a unique signature derived from the API interface's identifier and/or parameters, and that unique signature can identify thecorresponding primitive. In some embodiments, the API interface for a primitive may include a function call corresponding to the primitive. The API interface can also identify the data element(s) accessed by the primitive. In some embodiments, the data type(s) of the API interface's parameter(s) are the data type(s) of the primitive's data element(s), and the address(es) of theprimitive's data element(s) may be derived from the argument(s) to the API interface that are specified in the source code 612, and that are incorporated in the executable software 616. Embodiments have been described in which source code 612 is transformed into executable software 616 by a compiler/linker 614. In some embodiments, source code 612 may include interpreted code, and tool chain 600 may include an interpreter fortransforming the interpreted code into executable software. A software loader 618 may load software 616 into a memory 650, which is accessible to processing device(s) 604 and may be dedicated to processing device(s) 604. In some embodiments, software loader 618 may send a request to primitive loader 624to adapt specialized processor(s) 602 to implement one or more primitives referenced by executable software 616. Adapting specialized processor(s) 602 to implement primitives invoked by software 616 at the time processor(s) 604 load the software may beadvantageous, at least in the sense that the specialized processor(s) 602 may already be configured to perform a primitive task at the time processor(s) 604 execute the API corresponding to the primitive. In some embodiments, primitives loader 624 mayinclude a resource manager 110 of a reconfigurable computing system 100, or a component thereof (e.g., a reconfiguration controller). In some embodiments, after software 616 begins executing on processor(s) 604, the processor(s) may request that the primitive loader 624 adapt specialized processor(s) 602 to implement one or more primitives referenced by the software 616. Dynamically adapting specialized processor(s) 602 to implement primitives invoked by software 616 while the software executes may be advantageous, at least in circumstances where it is not feasible to adapt specialized processor(s) 602 to implement oneor more of the primitives referenced by the software at the time the software is loaded. Software 616 may, for example, contain references to more primitives than can be simultaneously implemented on the available specialized processor(s). As anotherexample, specialized processor(s) 602 may be performing other tasks at the time software 616 is loaded. The primitive loader 624 may adapt specialized processor(s) 602 to implement one or more primitives included in primitives library 622. In some embodiments, adapting the specialized processor(s) requires communicating with one or morecontrollers to set parameter values that affect the operation of the specialized processor(s). In some embodiments, the specialized processor(s) include one or more reconfigurable computing module(s), and adapting the RCM(s) may involve communicatingwith a reconfiguration controller to reconfigure the RCM(s) to implement a representation of a primitive task (e.g., by loading FPGA configuration file(s) onto an RCM's FPGA(s)). Techniques for Performing Primitive Tasks on Specialized Processors FIG. 7 illustrates a method 700 for performing a primitive task on a specialized processor, according to some embodiments. In step 710, a processing device executes one or more instructions corresponding to a software construct. The softwareconstruct represents execution of a primitive task on a specialized processor. Generally, the software construct includes an invocation of a primitives library API interface (e.g., a function call to a primitives library API function). In step 720, the primitive is loaded onto one or more specialized processors. Loading the primitive generally includes adapting the specialized processor(s) to perform the primitive task. Alternatively, or in addition, loading the primitivemay include loading at least a portion of the primitive's input data from a storage device (e.g., storage 108 as shown in FIG. 1) into a memory accessible to the specialized processor(s) (e.g., memory 106 as shown in FIG. 1). As described above, the specialized processor(s) may be adapted to perform the primitive task before the processing device invokes the API interface corresponding to the primitive (e.g., when the software that references the API interface isloaded), or may be adapted to perform the primitive task in response to the processing device executing the API. To adapt the specialized processor(s), the processing device may send a suitable request to the specialized processor(s) (e.g., to resourcemanager 110 as shown in FIG. 1). In general, adapting the specialized processor(s) may include setting parameters that control the operation of the specialized processor(s), loading software onto the specialized processor(s), and/or reconfiguring thehardware of the specialized processor(s). In some embodiments, adapting the specialized processor(s) includes reconfiguring one or more reconfigurable devices (e.g., RCMs 102 as shown in FIG. 1) to perform the primitive task. Reconfiguring an RCM toload a primitive may include configuring the RCM logic fabric to implement data-processing operations of the primitive task, and/or reconfiguring the RCM bus fabric to manage data flow. The primitive task may be apportioned among the specialized processors in a number of ways. For example, a single specialized processor may be adapted to perform the primitive task. In some embodiments, several specialized processors areadapted to perform the primitive task. For example, one specialized processor may be adapted to perform one portion of the primitive task, and another specialized processor may be adapted to perform another portion of the primitive task. In cases wherea number of specialized processors are adapted to perform the primitive task, the specialized processors may be adapted to perform the task in data-parallel fashion, with different specialized processors handling different subsets of the input data, orin any other suitable way. In step 730, in response to the processing device invoking the API interface, the specialized processor(s) perform at least a portion of the primitive task. Performing a portion of a primitive task may include using aspecialized-processor-based storage node manager to access data (""primitive data"") independently of the processing device. In some embodiments, the primitive data may be stored in a storage device accessible to both the specialized processor(s) (e.g.,specialized processor(s) 602 shown in FIG. 6) and the processing device (e.g., the processor(s) 604 shown in FIG. 6). In some embodiments, the address(es) of the primitive data may be passed as arguments to the API interface, or may be derived from thearguments passed to the API interface. In some embodiments, the address(es) of the primitive data may be communicated to the specialized processor(s) in response to the processing device invoking the API interface corresponding to the primitive. Any suitable specialized-processor-based storage node manager may be used to access the primitive data, including, without limitation, a hardware-based storage node manager 132, 232, or 332 as described above with reference to FIGS. 1-4. Insome embodiments, the specialized-processor-based storage node manager may be implemented on the same specialized processor that performs the primitive task. In some embodiments, the specialized-processor-based storage node manager may be implemented ona specialized processor that is different from any of the specialized processor(s) performing the primitive task. In some embodiments, the specialized processor(s) performing the primitive task may include several specialized-processor-based storagenode managers (e.g., one storage node manager per specialized processor). In some embodiments, the primitive data may include at least two data elements with different bit widths (e.g., an array of 32-bit identifiers and a parallel array of 4-bit codes). The specialized-processor-based storage node manager may beconfigured to access and/or process two or more data elements with different bit widths in parallel, thereby making efficient use of storage, communication, and/or processing resources. In step 740, the specialized-processor-based storage node manager may store one or more results of the primitive task in a storage device. In some embodiments, the storage device may be accessible to the processing device that executed theprimitive API (i.e., the processor(s) 604 shown in FIG. 6). In some embodiments, the specialized-processor-based storage node manager may store the results of the primitive task in the storage device independently of the processing device and/or anyother processor. In step 750, the general purpose processing device accesses the primitive task's stored result(s) through an operating system, so that a software application executed by such processing device (e.g., the processor(s) 604) can use theresults generated by the specialized processor(s). FIG. 8 illustrates a method for performing a primitive task on a computing system 800, according to some embodiments. In particular, FIG. 8 shows how, in some embodiments, the components of a computing system 800 interact with each other toimplement a method for performing a primitive task. The computing system 800 includes one or more reconfigurable computing modules (RCMs) 802, memory 806, storage 808, one or more processors 804, and a reconfigurable computing resource manager 810,which may include a reconfiguration controller 830 and a storage node manager 832. Some embodiments of these components are described above with reference to FIGS. 1-4. For brevity, these descriptions are not repeated here. The method of FIG. 8 may include one or more of steps 852-870. At step 852, processor 804 executes a compiled API 822 corresponding to a primitive task. In response, at step 853, resource manager 810 determines whether RCM(s) 802 are alreadyconfigured to implement the primitive task. At steps 854-860, reconfiguration controller 830 uses storage node manager 832 to retrieve a representation 844 of the task from storage 808. Alternatively or in addition, the reconfiguration controller mayrely on the operating system to access the task representation 844 from the storage 808, from processor memory 890 (e.g., memory 250 shown in FIG. 2), and/or from processor storage 892 (e.g., storage 260 shown in FIG. 2). At step 861, reconfigurationcontroller 830 reconfigures reconfigurable computing module(s) 802 to implement the task representation 844. At step 862, resource manager 810 instructs RCM(s) 802 to begin performing the primitive task. Alternatively, at step 894, processor 804instructs RCM(s) 802 to begin performing the primitive task. The computing module(s) then perform the task, which includes using storage node manager 832 in steps 864-870 to retrieve the task's input data 840 from storage 808. Some embodiments of steps852-870 for performing a primitive task on a reconfigurable computing system 800 are described in further detail below. At step 852, while executing instructions of software 820, processor 804 executes a compiled API 822 to a primitive. In one example, the API 822 includes a function call ""PrimitiveApi"", and the argument to the function call is the address instorage 808 of a data element ""prim_data"". In response to invocation of API primitive interface 822, processor 804 sends a request to resource manager 810 for RCM(s) 802 to perform the corresponding primitive task with the specified data. A request to perform a primitive task may identify the primitive and/or the primitive data using any suitable technique. In some embodiments, the primitives in primitives library 842 may have unique identifiers, and the request may include theunique identifier of the requested primitive. In some embodiments, the request may include the address (e.g., in storage 808 or within the primitives library) of the requested primitive or a portion thereof (e.g., a complete or partial representation ofthe primitive task), and/or the primitive data. In response to receiving a request to perform a primitive task, resource manager 810 may determine, at step 853, whether the RCM(s) 802 are configured to perform the requested primitive task. If the resource manager determines, in step 853,that the RCM(s) are not configured to perform the requested primitive task, the resource manager may use resource configuration controller 830 to reconfigure the RCM(s) 802 to implement the requested primitive. In particular, reconfiguration controller 830 may reconfigure the RCM(s) 802 to implement a representation of a primitive task corresponding to the requested primitive. Reconfiguration controller 830 may obtain the primitive task representation844 using any suitable technique. In some embodiments, reconfiguration controller 830 may receive the primitive task representation from processor 804 (e.g., when processor 804 invokes the primitive's API interface). In some embodiments,reconfiguration controller 830 uses the information identifying the requested primitive to obtain the primitive task representation 844 from storage 808, processor memory 890, and/or processor storage 892. A technique for obtaining a primitive task representation 844 from storage 808 may include steps 854-860. In step 854, reconfiguration controller 830 may instruct storage node manager 832 to load the task representation corresponding to therequested primitive. In some embodiments, a primitives library file 842 associated with the requested primitive may be stored in storage 808. In steps 856-858, storage node manager 832 may request and receive the portion of the primitives library file842 containing the requested primitive task representation 844. In some embodiments, the primitives library file and the primitives contained therein may be accessible to storage node manager 832 independently of any other processing device. In step860, storage node manager 832 may return the requested task representation 844 to reconfiguration controller 830. In step 861, reconfiguration controller may use primitive task representation 844 to reconfigure the RCM(s) 802 to implement the requested primitive. In some embodiments, a single RCM may be configured to implement the primitive. In someembodiments, several RCMs may be configured to implement the primitive, with the primitive being implemented in part on one RCM and in part on at least one other RCM. After resource manager 810 reconfigures the RCM(s) 802 to perform the requested primitive task, the resource manager may, in step 862, initiate execution of the primitive task on the RCM(s). Alternatively, if the resource manager determines, instep 853, that the RCM(s) are configured to perform the requested primitive task, the resource manager may, in step 862, initiate execution of the primitive task on RCM(s) 802. In some embodiments, instead of resource manager 810 initiating execution ofthe primitive task in step 862, processor 804 may initiate execution of the primitive task on the RCM(s) in step 894. During execution of the primitive task, RCM(s) 802 may access data stored in storage 808, including, without limitation, the data ""prim_data"" identified in the invocation of the primitive interface. In step 864, the RCM(s) 802 may instructstorage node manager 832 to load specified data (e.g., prim_data 840). In steps 866-868, storage node manager 832 may request and receive the specified data from storage 808. In various embodiments, the specified data is accessible to storage nodemanager 832 independently of any other processing device. In step 870, storage node manager 832 may send the specified data to RCM(s) 802. As the foregoing example demonstrates, in some embodiments, a primitive representation and data accessed by the primitive may be stored in the same storage module (e.g., in the same storage device). For example, a primitives library filecontaining the primitive and a data file containing data accessed by the primitive may be stored in the same storage module. In some embodiments, the primitive and its data may be stored in different storage modules. As the foregoing example further demonstrates, one or more RCMs 802 may be configured to implement a primitive before the API interface to the primitive is invoked by processor 804. In some embodiments, reconfiguration controller 830 mayreconfigure the RCM(s) to implement a specified primitive in response to the loading of software that references the primitive, in response to processor 804 executing an instruction directing the reconfiguration controller to reconfigure the RCM(s),and/or in response to any other suitable event. In the foregoing example, a hardware-based storage node manager 832 is used to retrieve data associated with a primitive. In some embodiments, the same reconfigurable computing module may implement at least a portion of hardware-based storagenode manager 832 and at least a portion of the specified primitive. In some embodiments, different RCMs may implement hardware-based storage node manager 832 and the specified primitive. In some embodiments, each one of several RCMs may implement arespective specified primitive, and each RCM may implement a respective hardware-based storage node manager or a portion of a common hardware-based storage node manager. In various embodiments, during the execution of a primitive, the RCM(s) 802 mayaccess the memory 806 directly, without using the storage node manager 832 and/or any other processor (except that integrated with the memory 806), e.g., to store partial results. The data retrieved from the storage 808 by the storage node manager 832(e.g., prim_data 840) may be cached in the memory 806, and may be accessed therefrom by the RCM(s) 802. The memory 806 may include one or more memory modules accessible only by the RCM(s) 802, one or more memory modules that can be accessed only by theprocessor(s) 804, and one or more memory modules that can be accessed by both the RCM(s) 802 and the processor(s) 804. Further Description of Some Embodiments Embodiments have been described in which a computing system 100 includes one or more reconfigurable computing module(s) 102 configurable to perform primitive tasks and a resource manager 110 adapted to manage the computing system's resources. In some embodiments, a computing module may be implemented using any suitable processing device, including, without limitation, an application-specific integrated circuit (ASIC), application-specific instruction-set processor (ASIP), digital signalprocessor (DSP), physics processing unit (PPU), graphics processing unit (GPU), network processor (NP), general-purpose programmable processor (e.g., CPU), microprocessor, microcontroller, multicore processor, and/or any other device suitable forperforming the specified primitive tasks. In some embodiments, a computing system may include at least one ASIC adapted to perform a searching primitive, at least one ASIC adapted to perform a counting primitive, and/or at least one ASIC adapted toperform a sorting primitive. Embodiments have been described in which a reconfigurable computing system uses a hardware-based storage node manager to manage communication between one or more reconfigurable computing modules and one or more storage nodes. However, use ofthe hardware-based storage node manager is not limited to reconfigurable computing systems. In some embodiments, a hardware-based storage node manager may be used to manage communication between a storage node and any suitable processing device (e.g.,an ASIC adapted to perform a primitive task). Embodiments have been described in which a hardware-based storage node manager is implemented, at least in part, using reconfigurable hardware (e.g., one or more FPGAs). However, implementations of the hardware-based storage node manager arenot limited to reconfigurable hardware. In some embodiments, a hardware-based storage node manager may be implemented without using reconfigurable hardware. In some embodiments, a hardware-based storage node manager may be implemented, at least inpart, using one or more ASICs and/or any other suitable processing device. Embodiments have been described in which a processing unit of a specialized processor (e.g., a reconfigurable partition of an RCM) is configured to implement one or more primitives. In some embodiments, multiple processing units may beconfigured to implement a single primitive. Embodiments have been described in which ""storage"" includes non-volatile memory. In some embodiments, ""storage"" may include volatile memory. Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations,modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only. Various aspects of the present disclosure may be used alone, in combination, or in a variety of arrangements not specifically described in the foregoing, and the invention is therefore not limited in its application to the details andarrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.TERMINOLOGY The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The indefinite articles ""a"" and ""an,"" as used in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean ""at least one."" The phrase ""and/or,"" as used in the specification and in the claims,should be understood to mean ""either or both"" of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with ""and/or"" should be construed in the samefashion, i.e., ""one or more"" of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the ""and/or"" clause, whether related or unrelated to those elements specifically identified. Thus, asa non-limiting example, a reference to ""A and/or B"", when used in conjunction with open-ended language such as ""comprising"" can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionallyincluding elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc. As used in the specification and in the claims, ""or"" should be understood to have the same meaning as ""and/or"" as defined above. For example, when separating items in a list, ""or"" or ""and/or"" shall be interpreted as being inclusive, i.e., theinclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as ""only one of or ""exactly one of,"" or, when used in theclaims, ""consisting of,"" will refer to the inclusion of exactly one element of a number or list of elements. In general, the term ""or"" as used shall only be interpreted as indicating exclusive alternatives (i.e. ""one or the other but not both"") whenpreceded by terms of exclusivity, such as ""either,"" ""one of,"" ""only one of,"" or ""exactly one of."" ""Consisting essentially of,"" when used in the claims, shall have its ordinary meaning as used in the field of patent law. As used in the specification and in the claims, the phrase ""at least one,"" in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements,but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally bepresent other than the elements specifically identified within the list of elements to which the phrase ""at least one"" refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, ""at least one of Aand B"" (or, equivalently, ""at least one of A or B,"" or, equivalently ""at least one of A and/or B"") can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B);in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one,optionally including more than one, B (and optionally including other elements); etc. The use of ""including,"" ""comprising,"" ""having,"" ""containing,"" ""involving,"" and variations thereof, is meant to encompass the items listed thereafter and additional items. Use of ordinal terms such as ""first,"" ""second,"" ""third,"" etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of amethod are performed. Ordinal terms are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term), to distinguish the claim elements.EQUIVALENTS While the invention has been particularly shown and described with reference to specific embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spiritand scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced."
10|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=40&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Secure active element machine|Based upon the principle of Turing incomputability, and novel properties of the Active Element Machine, a malware-resistant computing machine is constructed. This new computing machine is a non-Turing, non-register machine (non von-Neumann), called an Active Element Machine (AEM). AEM programs are designed so that the purpose of the computation is difficult to apprehend by an adversary and hijack with malware. These methods can help hinder reverse engineering of proprietary algorithms and hardware design. Using quantum randomness, the AEM can deterministically execute a universal digital computer program with active element firing patterns that are Turing incomputable. In some embodiments, a more powerful computational procedure is demonstrated than Turing's computational procedure (digital computer procedure). Current digital computer algorithms can be derived or designed with a Turing machine computational procedure. A novel class of computing machines is built where the purpose of the program's execution is difficult to apprehend (Turing incomputable).|
11|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=17&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Integrating map-reduce into a distributed relational database|A computer readable storage medium includes executable instructions to define a map-reduce document that coordinates processing of data in a distributed database. The map-reduce document complies with a map-reduce specification that integrates map-reduce functions with queries in a query language. The operations specified by the map-reduce document are executed in the distributed database.|
12|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=49&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Modular beverage dispenser having a build-in cold plate and carbonator|A modular beverage dispenser for engagement with bag-in-box or other source of pressurized concentrate and a pressurized ambient water source, such as city water, is provided. The dispenser has a housing having housing walls, the walls defining an interior space, the interior having interior walls defining a multiple of interior spaces. The housing engages either a flange (configured to engage a perimeter of a countertop drop-in cutout) or legs configured to depend downward from the housing to support the same above a support surface. An ice container is provided for receiving ice therein configured to engage the housing so as to be substantially within the interior space. A cold plate is provided with a multiplicity of cold plate contained fluid lines therein adapted to engage the ice container so as to be cooled by the contents thereof. A carbonator is located in a first interior space.|
13|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=11&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Sharing of first class objects across multiple interpreted programming languages|Systems and methods are disclosed for enabling users to write scripting code in a first scripting language, and then use a second scripting language to call language constructs written in that first scripting language. Functions, Class Definitions, Class Instances, Modules and other language constructs are treated as first-class objects that can be shared across the different scripting languages. The techniques disclosed herein are also applicable to domain-specific languages. As part of the methodology, a respective underlying representation of each of these object types is designed as an interface and then that interface is implemented in each scripting language. In addition, code is written in each scripting language implementation to allow the latter to use the interface to represent a Function, Class, or other language construct.|
14|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=7&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Generation of language bindings for libraries using data from compiler generated debug information|Described herein is a method and apparatus for generating automatic language bindings. The method includes receiving a request for a first program module in a first language from a second program module in a second language. A binding module is created in the second language in response to the request, where the binding module is generated from debug data of the first program module. The binding module is returned to the second program module. The second program module can then access the functionality of the first program module through use of the functions of the binding module.|
15|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=3&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Native service controller|In one respect, there is provided a system for loading managed applications. The system may include at least one processor and at least one memory. The memory may include program code which when executed by the at least one memory provides operations including: generating a single process, the generating comprising running a native code executable, the running of the native code execute loading a loader manager as part of the single process; loading, by the loader manager running within the single process, a runtime environment corresponding to a non-native code application; and loading, by the loader manager, the non-native code application, the non-native code application being loaded to run as part of the single process.|"1. A system, comprising: at least one processor; and at least one memory including program code which when executed by the at least one processor provides operationscomprising: generating a single process, the generating comprising running a native code executable, the running of the native code executable comprises loading a loader manager as part of the single process; loading, by the loader manager runningwithin the single process, a runtime environment corresponding to a non-native code application; and loading, by the loader manager, the non-native code application, the non-native code application being loaded to run as part of the single process. 2. The system of claim 1, wherein the operations further comprise: exchanging data between the non-native code application and another application loaded by the loader manager to run as part of the single process, the exchanging of data betweenthe non-native code application and the other application being performed without using one or more inter process communication (IPC) mechanisms. 3. The system of claim 1, wherein the loader manager is written in a native code programming language. 4. The system of claim 1, wherein the operations further comprise: loading, by the loader manager, another application, the other application being loaded to run as part of the single process. 5. The system of claim 4, wherein the other application comprises another non-native code application, and wherein the loader manager further loads a runtime environment corresponding to the other non-native code application. 6. The system of claim 4, wherein the other application comprises a native code application. 7. The system of claim 1, wherein the runtime environment corresponding to the non-native code application comprises a Common Language Runtime (CLR) environment, a Mono Runtime environment, a Ruby runtime environment, or a Python runtimeenvironment. 8. The system of claim 1, wherein the non-native code application comprises an application that requires the loading of the corresponding runtime environment prior to execution. 9. The system of claim 1, wherein the operations further comprise: loading, by the loader manager, a native code dynamic link library as part of the single process. 10. The system of claim 9, wherein the non-native code application and the native code dynamic link library are configured to provide services adapted to operate in a background of a running operating system. 11. The system of claim 1, wherein the running of the native code executable generates at least a first thread and a second thread. 12. The system of claim 11, wherein the first thread is configured report a running status of the native code executable to a scheduler of an operating system, and wherein the second thread is configured to yield to the first thread by atleast: determining, when the second thread is scheduled to run by the scheduler, whether the running status of the native code executable has been reported to the scheduler; in response to determining that the running status of the native codeexecutable has not been reported to the scheduler, yielding to the first thread by at least transmitting, to the scheduler, a message that causes the scheduler to start running the first thread or a third thread. 13. The system of claim 12, wherein the yielding by the second thread allows the first thread to run ahead of the second thread and to report the running status to the scheduler before a loading of the native code executable is timed out. 14. A method, comprising: generating, by at least one processor, a single process, the generating comprising running a native code executable, the running of the native code executable comprises loading a loader manager as part of the singleprocess; loading, by the loader manager running within the single process, a runtime environment corresponding to a non-native code application; and loading, by the loader manager, the non-native code application, the non-native code application beingloaded to run as part of the single process. 15. The method of claim 14, further comprising: loading, by the loader manager, another application, the other application being loaded to run as part of the single process. 16. The method of claim 15, further comprising: exchanging data between the non-native code application and the other application, the exchanging of data between the non-native code application and the other application being performed withoutusing one or more inter process communication (IPC) mechanisms. 17. The method of claim 15, wherein the other application comprises another non-native code application, and wherein the loader manager further loads a runtime environment corresponding to the other non-native code application. 18. The method of claim 15, wherein the other application comprises a native code application. 19. The method of claim 14, further comprising: loading, by the loader manager, a native code dynamic link library as part of the single process, wherein the non-native code application and the native code dynamic link library are configured toprovide services adapted to operate in a background of a running operating system. 20. The method of claim 14, wherein the running of the native code executable generates at least a first thread and a second thread. 21. The method of claim 20, wherein the first thread is configured report a running status of the native code executable to a scheduler of an operating system, and wherein the second thread is configured to yield to the first thread by atleast: determining, when the second thread is scheduled to run by the scheduler, whether the running status of the native code executable has been reported to the scheduler; in response to determining that the running status of the native codeexecutable has not been reported to the scheduler, yielding to the first thread by at least transmitting, to the scheduler, a message that causes the scheduler to start running the first thread or a third thread. 22. The method of claim 21, wherein the yielding by the second thread allows the first thread to run ahead of the second thread and to report the running status to the scheduler before a loading of the native code executable is timed out. 23. The method of claim 14, wherein the runtime environment corresponding to the non-native code application comprises a Common Language Runtime (CLR) environment, a Mono Runtime environment, a Ruby runtime environment, or a Python runtimeenvironment. 24. The method of claim 14, wherein the non-native code application comprises an application that requires the loading of the corresponding runtime environment prior to execution. 25. A computer program product comprising a non-transitory machine-readable medium storing instructions that, when executed by at least one programmable processor, cause the at least one programmable processor to perform operations comprising:generating a single process, the generating comprising running a native code executable, the running of the native code executable comprises loading a loader manager as part of the single process; loading, by the loader manager running within the singleprocess, a runtime environment corresponding to a non-native code application; and loading, by the loader manager, the non-native code application, the non-native code application being loaded to run as part of the single process. Description TECHNICAL FIELD The subject matter described herein relates generally to the deployment of applications and more specifically to a native service controller.BACKGROUND An application written in native code (e.g., C, C++) can be compiled directly into machine code and executed by a processor (e.g., an x86-class processor available from Intel Corporation of Santa Clara, Calif.). By contrast, executing anapplication written in non-native or managed code (e.g., C#, Java, Ruby, Python) can require a virtual environment (e.g., NET Runtime, Java Virtual Machine (JavaVM)) to provide a software emulation of a particular processor. Thus, an operation systemmay be required to load a particular runtime environment prior to loading a corresponding non-native code application. For example, a runtime loader (e.g., NET runtime loader) can be invoked to load the runtime environment (Common Language Runtime (CLR), Mono Runtime) for non-native (e.g., .NET) applications. The runtime loader can define and publish a nativeprogramming interface (e.g., C# Hosting Interfaces in Windows, Java Native Interface for Java applications, and Mono Embedding API for Mono Runtime.), which can be used by native code to load a corresponding runtime environment. The runtime loader canbe written in native programming language (e.g., C, C++) and compiled as a dynamic linked library that can be loaded directly by an operation system.SUMMARY Systems, methods, and articles of manufacture, including computer program products, are provided for loading managed applications. In some example embodiments, there is provided a system that includes at least one processor and at least onememory. The memory may include program code which when executed by the at least one memory provides operations including: generating a single process, the generating comprising running a native code executable, the running of the native code executeloading a loader manager as part of the single process; loading, by the loader manager running within the single process, a runtime environment corresponding to a non-native code application; and loading, by the loader manager, the non-native codeapplication, the non-native code application being loaded to run as part of the single process. In some variations, one or more features disclosed herein including the following features can optionally be included in any feasible combination. The operations can further include exchanging data between the non-native code application andanother application loaded by the loader manager to run as part of the single process, the exchanging of data between the non-native code application and the other application being performed without using one or more inter process communication (IPC)mechanisms. The loader manager can be written in a native code programming language. In some variations, the operations can further include loading, by the loader manager, another application, the other application being loaded to run as part of the single process. The other application can be another non-native codeapplication, and the loader manager further can further load a runtime environment corresponding to the other non-native code application. Alternately, the other application can be a native code application. The runtime environment corresponding to thenon-native code application can be a CLR environment, a Mono Runtime environment, a Ruby runtime environment, or a Python runtime environment. The non-native code application can be an application that requires the loading of the corresponding runtimeenvironment prior to execution. The loader manager can be written in a native code programming language. The loading of the at least one runtime environment can include loading a first non-native runtime environment corresponding to a first non-native code application, andloading a second non-native runtime environment corresponding to a second non-native code application. The first and/or second non-native runtime environment can comprise a CLR environment, a Mono Runtime environment, a Ruby runtime environment, or aPython runtime environment. The first and/or second non-native code application can comprise an application written in C#, Ruby, or Python. In some variations, the system can further be configured to load, by the loader manager, at least one native code dynamic link library as part of the single process. The non-native code application and the native code dynamic link library canbe configured to provide services adapted to operate in a background of a running operating system. In some variations, the running of the native code executable can generate at least a first thread and a second thread. The first thread can be configured report a running status of the native code executable to a scheduler of an operatingsystem. The second thread can configured to yield to the first thread by at least: determining, when the second thread is scheduled to run by the scheduler, whether the running status of the native code executable has been reported to the scheduler; inresponse to determining that the running status of the native code executable has not been reported to the scheduler, yielding to the first thread by at least transmitting, to the scheduler, a message that causes the scheduler to start running the firstthread or a third thread. The yielding by the second thread allows the first thread to run ahead of the second thread and to report the running status to the scheduler before a loading of the native code executable is timed out. Implementations of the current subject matter can include, but are not limited to, methods consistent with the descriptions provided herein as well as articles that comprise a tangibly embodied machine-readable medium operable to cause one ormore machines (e.g., computers, etc.) to result in operations implementing one or more of the described features. Similarly, computer systems are also described that may include one or more processors and one or more memories coupled to the one or moreprocessors. A memory, which can include a non-transitory computer-readable or machine-readable storage medium, may include, encode, store, or the like one or more programs that cause one or more processors to perform one or more of the operationsdescribed herein. Computer implemented methods consistent with one or more implementations of the current subject matter can be implemented by one or more data processors residing in a single computing system or multiple computing systems. Suchmultiple computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g. the Internet, a wireless wide area network, alocal area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc. The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from thedescription and drawings, and from the claims. While certain features of the currently disclosed subject matter are described for illustrative purposes, it should be readily understood that such features are not intended to be limiting. The claims thatfollow this disclosure are intended to define the scope of the protected subject matter. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, show certain aspects of the subject matter disclosed herein and, together with the description, help explain some of the principles associated withthe disclosed implementations. In the drawings, FIG. 1 depicts a block diagram illustrating a native service controller consistent with implementations of the current subject matter; FIG. 2A depicts code implementing a native service controller consistent with implementations of the current subject matter; FIG. 2B depicts code implementing a native service controller consistent with implementations of the current subject matter; FIG. 2C depicts code implementing a native service controller consistent with implementations of the current subject matter; FIG. 3 depicts a block diagram illustrating a system consistent with implementations of the current subject matter; FIG. 4 depicts a flowchart illustrating a process for generating a native service controller consistent with implementations of the current subject matter; and FIG. 5 depicts a flowchart illustrating a process for loading a native service controller consistent with implementations of the current subject matter.DETAILED DESCRIPTION As noted above, loaders can be required to load different runtime environments for applications written in different non-native programming languages (e.g., C#, Java, Ruby, Python). Loading applications in this manner can generate a separateprocess for each different native code and non-native code application. The exchange of information between processes is typically conducted using a set of IPC mechanisms including, for example, sockets, pipes, and message queues. But exchangingsensitive information using one or more IPC mechanisms can require extra implementation efforts (e.g., information encryption). This can incur additional computing resources (e.g., processing time, memory) but does not thoroughly remove the risk ofexposing sensitive information. As such, in some implementations of the current subject matter, a native service controller can enable execution of multiple native code components that are implemented as a dynamic-link library, and non-native code applications and/ornon-native code dynamic libraries in a single process. Native code applications (e.g., C, C++) are applications that can be run directly on a particular (e.g., x86 processor) while non-native code applications (e.g., C#, Java, Ruby, Python) areapplications that can be run in a virtual environment that emulates a particular processor. Native and non-native code executed in a single process share the same virtual memory space, thereby obviating the need for using one or more IPC mechanisms. Inthis manner, native and non-native code can exchange information without incurring the additional computing resources associated with IPC mechanisms all while avoiding the risk of exposing sensitive information. The native service controller can be an executable, which is a file that is capable of being executed or run as a program by a processor. The native service controller can be written in native code can thus be loaded by an operating systemnative program loader. In some implementations of the current subject matter, the native service controller can be a wrapper that encapsulates a plurality of applications including one or more non-native code applications. For example, the nativeservice controller can include applications for the NET framework (e.g., developed by Microsoft Corporation of Redmond, Wash.) and/or applications written in Java (e.g., developed by Sun Microsystems of Santa Clara, Calif.), Ruby (e.g., developed by theRails Core Team), and/or Python (e.g., developed by the Python Software Foundation of Delaware). According to implementations of the current subject matter, each of the plurality of native and/or non-native code applications can be adapted to provideone or more corresponding services (e.g., Windows services) adapted to operate in the background of a running operating system. Moreover, the native service controller can include a native-code application configured to load one or more non-nativeruntime environments including, for example, CLR, Mono, Java, Python, and Ruby. Subsequent to loading the appropriate non-native runtime environments, the native code application can be further configured to load the one or more non-native codeapplications encapsulated in the native service controller. In some implementations of the current subject matter, loading the native service controller can trigger a plurality of threads, which are simultaneously running tasks. Specifically, loading the native service controller can generate a main orprimary thread. The main thread is a thread that is configured to generate one or more worker threads. Moreover, the main thread or a worker thread can be configured to report, to a scheduler of the operation system or its proxy (e.g., Windows ServiceControl Manager (SCM in Windows)), the running status (e.g., SERVICE RUNNING) of the native service controller. Meanwhile, the worker threads can be configured to perform one or more other tasks required for initializing the native service controller. According to some implementations of the current subject matter, the running status of the native service controller must be reported within a certain period of time (e.g., 30 seconds) in order to prevent the loading of the native servicecontroller from timing out. However, the operating system scheduler may schedule the threads to run without prioritizing the thread that is responsible for reporting the running status of the native service controller. Thus, the threads that are notresponsible for reporting the running status can be configured to yield (e.g., use of the central processing unit (CPU)) to the thread that is responsible for reporting the running status. These threads can be configured to yield until the runningstatus of the native service controller has been reported to the operating system scheduler or its proxy. Yielding to the thread responsible for reporting the running status can allow that thread to run and report the running status of the nativeservice controller within the required period of time (e.g., 30 seconds). Otherwise, a plurality of other threads can be scheduled (e.g., by the scheduler) to run ahead of the thread responsible for reporting the running status, thereby preventing thatthread from reporting the running status of the native service controller before the loading of the native service controller is timed out. FIG. 1 depicts a block diagram illustrating a native service controller 100 consistent with implementations of the current subject matter. Referring to FIG. 1, the native service controller 100 can be an executable (e.g., native.exe) that iswritten in native code (e.g., C, C++). As shown in FIG. 1, the native service controller 100 can implement a loader manager 110, which is native code configured to load one or more non-native code virtual environments through corresponding nativeprogramming interfaces. The native service controller 100 can further load, via the loader manager 110, one or more non-native code applications or dynamic libraries including, for example, a first non-native code 122 and a second non-native code 124. In addition, thenative service controller 100 can also load, via the loader manager 110, one or more native code dynamic libraries including, for example, a first native code dynamic-link library 132 and a second native code dynamic-link library 134. It should beappreciated that the native service controller 100 can be configured to load a different number of non-native code applications and/or dynamic libraries and/or native code dynamic libraries without departing from the scope of the present disclosure. As shown in FIG. 1, the native service controller 100 can be distributed (e.g., to one or more end users) in a distribution package 150 (e.g., software package) that includes the loader manager 110, the first non-native code 122, and the secondnative code dynamic-link library 134. As part of the distribution package 150, the loader manager 110 can be implemented as a dynamic-link library and/or a static link library. In some implementations of the current subject matter, the native servicecontroller 100 can be configured to load, via the loader manager 110, native and/or non-native code applications and/or dynamic libraries that are packaged and distributed with the native service controller 100 (e.g., in the distribution package 150). Alternately or additionally, the native service controller 100 can be configured to load, via the loader manager 110, native code dynamic libraries and/or non-native code applications and/or dynamic libraries that are not included in the distributionpackage 150. For instance, the native service controller 100 can be configured to load, via the loader manager 110, the second native code 124 and the first native code dynamic-link library 132. It should be appreciated that the native service controller 100 can be distributed without the loader manager 110 without departing from the scope of the present disclosure. In some implementations of the current subject matter, the loadermanager 110 can be standalone executable that can be executed by an operating system and/or a native code application (e.g., to load one or more other native code applications). The loader manager 110 can also be implemented as a dynamic-link librarythat can be loaded by an operating system and/or a native code application (e.g., to load one or more other native code applications). Alternately or additionally, the loader manager 110 can be part of an operating system or be open source code that isbuilt as part of a native code application. Referring again to FIG. 1, the plurality of non-native code applications and/or dynamic libraries (e.g., the first non-native code 122, the second non-native code 124) can be written in different non-native programming languages and thereforerequire different runtime environments. For example, the first non-native code 122 can be a NET application that requires a CLR or Mono Runtime environment while the second non-native code 124 can be a Ruby application that requires a Ruby runtimeenvironment. As such, the loader manager 110 can be configured to load the appropriate runtime environments for the non-native code applications and/or dynamic libraries (e.g., the first non-native code 122, the second non-native code 124). In some implementations of the current subject matter, the loader manager 110 can be further configured to load one or more non-native code applications and/or dynamic link libraries subsequent to loading the corresponding runtime environmentfor each applications. Loading the native service controller 100 can generate a single process within the same virtual memory space. According to implementations of the current subject matter, the plurality of native and/or non-native code applications included in the native service controller 100 are loaded (e.g., by the loader manager 110) as a part of the same process. Assuch, the native code dynamic libraries and/or the non-native code applications and/or dynamic libraries loaded by the native service controller 100 can share the same virtual memory space and are thus able to share data without using IPC. For example,the first non-native code 122 can communicate with one or more other applications (e.g., the second non-native code 124) by sending messages within the same process. Avoiding the use of IPC can prevent exposing sensitive data via the data exchangemechanisms (e.g., socket, pipe, message queue) that are typically associated with IPC. In some implementations of the current subject matter, non-native code applications or non-native code dynamic-link libraries can be written in a non-native programming language (e.g., C#, Java, Ruby). To execute applications written in anon-native programming language, a native programming interface can be required in order for the operating system or its proxy to be able to load the corresponding virtual environments. The native programming interface can provide a means for exchangingdata between native code and non-native code. As such, according to implementations of the current subject matter, the native service controller 100 can define and publish a single native programming interface that accepts, as an input parameter, acharacter string. The native programming interface can be used by both native and non-native code applications. The contents of character string can be transparent to the native service controller 100 and can be understood by only those applicationsengaged in the exchange of data. The contents of character string can be a command message and/or a data message. Alternately or additionally, the native service controller 100 can provide different pre-formatted character strings, which are understoodby different group of participating applications. In some implementations of the current subject matter, non-native programming language or its interface provides the means to share the same virtual memory space allocated to applications loaded in the same process. For instance, C# MarshalClass and number of native programming interfaces (e.g., GetShortArrayRegion) defined in Java Native Interface (JNI) can be used to share memory between native code and C# and Java. Thus, the native service controller 100 can allocate a chunk of memoryand share this chunk of memory with the other native code in the dynamic-link library and/or non-native code applications that were loaded in the same process. The contents of such shared memory can be produced by one participating native code ornon-native code and be consumed by other participating native code or non-native code. FIG. 2A depicts code 210 implementing the native service controller 100 consistent with implementations of the current subject matter. The code 210 shown in FIG. 2A can be included in the loader manager 110 to load the CLR environment for oneor more of the .NET applications. FIG. 2B depicts code 222 and code 224 for implementing the native service controller 100 consistent with implementations of the current subject matter. Referring to FIGS. 1 and 2A-B, the code 222 shown in FIG. 2B can be included in the loadermanager 110 to load one or more non-native code applications and/or dynamic libraries including, for example, the first non-native code 122 and the second non-native code 124. Meanwhile, the code 224 can implement a non-native code application and/ordynamic-link library including, for example, the first non-native code 122 and the second non-native code 124. FIG. 2C depicts code 230 implementing the native service controller 100 consistent with implementations of the current subject matter. Referring to FIGS. 1 and 2A-C, the code 230 shown in FIG. 2C can implement the exchange of data (e.g., viamessages) by a non-native code application (e.g., the first non-native code 122, the second non-native code 124) with other native and/or non-native code applications loaded by the native service controller 100. FIG. 3 depicts a block diagram illustrating a system 300 consistent with implementations of the current subject matter. Referring to FIGS. 1-3, the system 300 can include a service controller package generator module 312, a native codeapplication loader module 314, and an output module 316. In implementations of the current subject matter, the system 300 can be configured to generate and/or load the native service controller 100. In some implementations of the current subject matter, the service controller package generator module 312 can be configured to generate the distribution package 150 by generating an executable wrapper written in a native code programminglanguage. The service controller package generator module 312 can be further configured to encapsulate, within the native code wrapper, a native service controller along with a loader manager and/or a plurality of native code dynamic libraries and/ornon-native code applications and/or dynamic libraries. The loader manager can be written in a native code programming language (e.g., C, C++). For example, referring to FIG. 1, the service controller package generator 312 can be configured to generatethe distribution package 150 by encapsulating, in a native code executable, the native service controller 100, the loader manager 110, the first non-native code 122, and the second native code dynamic-link library 134. The native service controller 100can be loaded automatically by an operating system (e.g., at startup or after). The native code application loader module 314 can be configured to load one or more applications written in native code including, for example, the native service controller 100, which can be include in the distributed package 150. For example,the native code application loader module 314 can be configured to load the native service controller 100. According to some implementations of the current subject matter, the native code application loader module 314 can load the native servicecontroller 100 as one process while the native service controller 100 further loads, in the same process, a plurality of native code dynamic libraries and/or non-native code applications and/or dynamic libraries (e.g., the first non-native code 122, thesecond non-native code 124, the first native code dynamic-link library 132, the second native code dynamic-link library 134). Because the native service controller 100 loads the plurality of native code and/or non-native code applications in a singleprocess and in the same virtual memory space, the applications can share data via the shared virtual memory instead of exchanging data using one or more IPC mechanisms (e.g., sockets, pipes, message queues). According to some implementations of the current subject matter, loading the native service controller 100 can generate plurality of threads including, for example, a main thread and one or more worker threads. The scheduler of the operatingsystem can schedule the threads to run without prioritizing any one thread (e.g., main thread over the worker threads and/or vice versa). One of the plurality of threads (e.g., the main thread or one of the worker threads) is responsible for reportingthe running status of the native service controller 100 to the operating system scheduler. In order to ensure that the thread is able to report the running status of the native service controller 100 to the scheduler, the other threads can be configuredto yield (e.g., the CPU) whenever the other threads are scheduled (e.g., by the scheduler) to run. For instance, the threads not responsible for reporting the running status can be configured to transmit a SLEEP message to the operating systemscheduler, thereby causing the operating system scheduler to start running a next thread in the scheduler's queue. Yielding to the thread responsible for reporting the running status enables that thread to run and to report the running status of thenative service controller 100 before the loading of the native service controller 100 times out (e.g., within 30 seconds). In some implementations of the current subject matter, the native service controller 100 can be deployed (e.g., downloaded and/or installed) on one or more devices including, for example, a device 350. For instance, the native servicecontroller 100 can be deployed to run on the device 350, thereby allowing the first non-native code 122, the second non-native code 124, the first native code dynamic link library 132, and the second native code dynamic link library 134 to be loaded aspart of the same process. The native service controller 100 can be provided in any manner including, for example, as computer software, dedicated circuitry (e.g., application specific integrated circuits (ASICs)), and/or over a cloud platform. Forexample, as shown in FIG. 3, the device 350 can download the native service controller 100 via a wired and/or wireless network 340 (e.g., a local area network (LAN), a wide area network (WAN), and/or the Internet). FIG. 4 depicts a flowchart illustrating a process 400 for generating the native service controller 100 consistent with implementations of the current subject matter. Referring to FIGS. 1-4, the process 400 can be performed by the system 300. In some implementations of the current subject matter, the process 400 can be performed by the system 300 to generate one or more native service controllers including, for example, the native service controller 100. The system 300 can generate a distribution package that includes a native service controller (402). For instance, the system 300 can generate the distribution package 150. The system 300 can further include, in the distribution package 150,the native service controller 100. In some implementations of the current subject matter, the native service controller 110 is an executable written in native code and can therefore be loaded automatically by an operating system (e.g., at startup timeor after). The system 300 can encapsulate, in the distribution package, a loader manager and a plurality of native code and/or non-native code applications (404). For example, the system 300 can further include, in the distribution package 150, the loadermanager 110, the first non-native code 122, and the second native code dynamic link library 134. The system 300 can provide the distribution package such that the native service controller can cause to load, in a single process, the plurality of native code and/or non-native code applications included in the distribution package and one ormore external native code and/or non-native code applications (406). For example, the distribution package 150 can be provided as computer software, dedicated circuitry (e.g., ASICs), and/or over a cloud platform. Loading the native service controller100 can cause the loader manager 110 to execute. The loader manager 110 can be configured to load the appropriate non-native runtime environment for the first non-native code application 122, which is included with the distribution package 150. Theloader manager 110 can be further configured to load the appropriate non-native runtime environment for the second non-native code application 124, which is external to the distribution package 150. In addition, the loader manager 110 can be configured to load the first non-native code 122, the second non-native code 124, the first native code dynamic link library 132, and the second native code dynamic link library 134. Applicationsand/or dynamic link libraries loaded in this manner are part of a single process sharing the same virtual memory space. As such, the first non-native code 122, the second non-native code 124, the first native code dynamic link library, and the secondnative code dynamic link library 134 can share data without using any IPC mechanisms (e.g., sockets, pipes, and/or message queues). FIG. 5 depicts a flowchart illustrating a process 500 for loading a native service controller consistent with implementations of the current subject matter. Referring to FIGS. 1-3 and 5, the process 500 can be performed by a thread (e.g., mainthread, worker thread) that is generated during the loading of the native service controller 100. For example, loading the native service controller 100 can generate a main thread and a plurality of worker threads. The main threads and the plurality ofworker threads can be run in an order determined by a scheduler of an operating system. Furthermore, the main thread or one of the plurality of worker threads can be tasked with reporting the running status of the native service controller 100. A first thread that is not responsible for reporting the running status of the native service controller 100 can receive an indication to start running (502). For example, the scheduler of the operating system can schedule a main thread or aworker thread to run. However, the scheduler of the operating system does not prioritize an order in which the threads run based on which thread is responsible for reporting the running status of the native service controller 100. For instance, themain thread can be tasked with reporting the running status of the native service controller 100. But the scheduler can schedule one or more worker threads to run ahead of the main thread, thereby preventing the main thread from reporting a runningstatus of the native service controller 100 on a timely basis (e.g., before the loading of the native service controller 100 is timed out). As such, the first thread can determine whether the running status of the native service controller 100 has been reported (503). If the first thread determines that the running status of the native service controller 100 has not already beenreported (503--N), the first thread can yield to a second thread that is responsible for reporting the running status of the native service controller 100 (504). For example, the worker thread can yield to the main thread by transmitting a SLEEP messageto the scheduler, thereby forfeiting its opportunity to use the CPU and allowing the next scheduled thread to use the CPU instead. By yielding to the main thread, the worker thread can allow the main thread to run ahead of the worker thread. In thismanner, the main thread can have an opportunity to report the running status of the native service controller 100 to the scheduler before the loading of the native service controller 100 times out. Alternately, if the first thread determines that the running status of the native service controller 100 has been reported (503-Y), the first thread can run in accordance with the scheduling determined by the scheduler of the operating system(506). For example, once the main thread reports the running status of the native service controller 100, the worker thread can run as scheduled by the scheduler of the operating system. Implementations of the present disclosure can include, but are not limited to, methods consistent with the descriptions provided above as well as articles that comprise a tangibly embodied machine-readable medium operable to cause one or moremachines (e.g., computers, etc.) to result in operations implementing one or more of the described features. Similarly, computer systems are also described that can include one or more processors and one or more memories coupled to the one or moreprocessors. A memory, which can include a computer-readable storage medium, can include, encode, store, or the like one or more programs that cause one or more processors to perform one or more of the operations described herein. Computer implementedmethods consistent with one or more implementations of the current subject matter can be implemented by one or more data processors residing in a single computing system or multiple computing systems. Such multiple computing systems can be connected andcan exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g. the Internet, a wireless wide area network, a local area network, a wide area network, a wirednetwork, or the like), via a direct connection between one or more of the multiple computing systems, etc. One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs, field programmable gate arrays (FPGAs) computer hardware, firmware, software,and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can bespecial or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system can includeclients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers andhaving a client-server relationship to each other. These computer programs, which can also be referred to programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and can be implemented in a high-level procedurallanguage, an object-oriented programming language, a functional programming language, a logical programming language, and/or in assembly/machine language. As used herein, the term ""machine-readable medium"" refers to any computer program product,apparatus and/or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receivesmachine instructions as a machine-readable signal. The term ""machine-readable signal"" refers to any signal used to provide machine instructions and/or data to a programmable processor. The machine-readable medium can store such machine instructionsnon-transitorily, such as for example as would a non-transient solid-state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transientmanner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores. To provide for interaction with a user, one or more aspects or features of the subject matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display(LCD) or a light emitting diode (LED) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices can beused to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user can be received inany form, including, but not limited to, acoustic, speech, or tactile input. Other possible input devices include, but are not limited to, touch screens or other touch-sensitive devices such as single or multi-point resistive or capacitive trackpads,voice recognition hardware and software, optical scanners, optical pointers, digital MRI image capture devices and associated interpretation software, and the like. In the descriptions above and in the claims, phrases such as ""at least one of"" or ""one or more of"" may occur followed by a conjunctive list of elements or features. The term ""and/or"" may also occur in a list of two or more elements or features. Unless otherwise implicitly or explicitly contradicted by the context in which it used, such a phrase is intended to mean any of the listed elements or features individually or any of the recited elements or features in combination with any of the otherrecited elements or features. For example, the phrases ""at least one of A and B;"" ""one or more of A and B;"" and ""A and/or B"" are each intended to mean ""A alone, B alone, or A and B together."" A similar interpretation is also intended for lists includingthree or more items. For example, the phrases ""at least one of A, B, and C;"" ""one or more of A, B, and C;"" and ""A, B, and/or C"" are each intended to mean ""A alone, B alone, C alone, A and B together, A and C together, B and C together, or A and B and Ctogether."" Use of the term ""based on,"" above and in the claims is intended to mean, ""based at least in part on,"" such that an unrecited feature or element is also permissible. The subject matter described herein can be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementationsconsistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. Although a few variations have been described in detail above, other modifications or additionsare possible. In particular, further features and/or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and subcombinations of the disclosedfeatures and/or combinations and subcombinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and/or described herein do not necessarily require the particular order shown, or sequentialorder, to achieve desirable results. Other implementations can be within the scope of the following claim."
16|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=38&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Cloud-based hub for facilitating distribution and consumption of application programming interfaces|Systems and methods for facilitating distribution of application programming interfaces (APIs) in a social hub are described herein. The social API hub enables users (i.e., API consumers) to access (e.g., search, test, and/or otherwise utilize or consume) APIs that other users (i.e., API developers) submitted to the hub in a standardized manner. Additionally, users can wrap submitted APIs in a standard description format and add various add-ons on top of an existing API infrastructure in order to provide additional functionality.|"1. A method comprising: receiving, at a management system, user-generated parameters describing functionality associated with an application program interface (API); configuring, at the management system, a proxy for providing secure communications between an API server and a client; generating, at the management system, a plurality of client libraries based on the user-generated parameters, wherein the clientlibraries are utilized by users of the management system to consume the API, and wherein generating the plurality of client libraries includes bringing the client libraries into existence; providing, at the management system, a plurality of add-ons tothe client, wherein each add-on of the plurality of add-ons provides functionality in addition to the API; receiving, at the management system, an indication of a selection of an add-on of the plurality of add-ons; associating, at the managementsystem, the add-on of the plurality of add-ons with the API to provide functionality in addition to the API; receiving, at the management system, a request to publish the API; and publishing, at the management system, the API via an online platform. 2. The method of claim 1, wherein the API returns JavaScript Object Notation (JSON) data. 3. The method of claim 1, further comprising: receiving, at the management system, a request from one of the plurality of users of the management system to consume the API. 4. The method of claim 1, wherein the online platform comprises an API hub. 5. The method of claim 1, further comprising: automatically categorizing, at the management system, the API based on the user-generated parameters; and storing the API in an API data store. 6. The method of claim 1, further comprising: after publishing the API via the online platform, providing, at the management system, a custom uniform resource locator (URL) for the API, wherein the URL is configured for user registration andauthentication. 7. The method of claim 1, further comprising: generating, at the management system, customized documentation based on the user-generated parameters. 8. The method of claim 1, wherein an add-on of the plurality of add-ons comprises an add-on including billing system functionality. 9. The method of claim 1, wherein an add-on of the plurality of add-ons comprises an add-on for user authentication. 10. The method of claim 1, wherein an add-on of the plurality of add-ons comprises an add-on for analytics associated with the use of the API. 11. The method of claim 1, wherein an add-on of the plurality of add-ons comprises an add-on for a request limit check to the API, the request limit check indicating the number of requests allowed per a specified time period. 12. The method of claim 1, wherein configuring the proxy comprises configuring one or more fields in the online platform. 13. The method of claim 1, further comprising: receiving, at the management system, a request to test the API within the online platform; and responsive to the request, testing the API within the online platform. 14. The method of claim 1, wherein the parameters are received via an XML description file. 15. The method of claim 1, further comprising: receiving, at the management system, one or more contributions to the API from a third-party developer, wherein the third-party developer is different than an original developer of the API; andpublishing, at the management system, the updated API. 16. The method of claim 1, wherein publishing the API via the online platform comprises: providing, at the management system, a number of third-party developers that consume and contribute to the development of the API. 17. A method comprising: receiving, at a management system, a text-based search query indicating API specific search criteria; searching, at the management system, a categorized API data store using the API specific search criteria; providing, at the management system, one or more APIs that match the API specific search criteria via an online platform; providing, at the management system, a plurality of add-ons, wherein each add-on of the plurality of add-ons provides functionalityin addition to the API; responsive to providing the one or more APIs, receiving, at the management system, a selection of a first API of the one or more APIs that match the API specific search criteria; responsive to providing the plurality of add-ons,receiving, at the management system, an indication of a selection of an add-on of the plurality of add-ons; associating, at the management system, the add-on of the plurality of add-ons with the first API to provide functionality in addition to thefirst API; responsive to receiving the selection of the first API, providing, at the management system, a plurality of automatically generated client libraries associated with the first API; receiving, at the management system, a selection of a firstclient library of a plurality automatically generated client libraries associated with the first API; determining, at the management system, whether an API consumer has indicated to test the first API; testing the first API at the management system inresponse the determination of whether the API consumer has indicated to test the first API; and providing, at the management system, the first API via the online platform. 18. The method of claim 17, wherein providing the first API comprises: providing the first automatically generated client library associated with the first API. 19. The method of claim 17, wherein the text-based search inquiry indicates a type of an API, functionality of an API, or an API name. 20. The method of claim 17, further comprising: receiving, at the management system, a request to test the first API via a test console that is embedded in the online platform. 21. The method of claim 17, further comprising: responsive to receiving the selection of the first API, providing, at the management system, automatically generated documentation associated with that API. 22. The method of claim 17, wherein providing the one or more APIs that match the text-based search inquiry via an online platform comprises: providing categories associated with the one or more APIs; and providing an indication of the numberof third-party developers that contribute to the development of the API. 23. The method of claim 22, further comprising: providing the identities of the third-party developers that contribute to the development of the API. 24. The method of claim 22, further comprising: providing a forum indicating comments from the third-party developers that contribute to the development of the API. 25. The method of claim 17, further comprising: responsive to providing the first API via the online platform, updating, at the management system, third-party usage of the first API. 26. The method of claim 17, wherein said each library was automatically generated in a different one of the following programming languages: Bash, Ruby, Python, PHP, Node.js, C#, Java, or Objective-C. 27. A management system comprising: a network interface configured to receive user-generated parameters describing functionality associated with an application program interface (API) and a request to publish the API; and a processing systemconfigured to configure a proxy for providing secure communications between an API server and a client, automatically generate a plurality of client libraries based on the user-generated parameters, provide a plurality of add-ons, wherein each add-on ofthe plurality of add-ons provides functionality in addition to the API, receive an indication of a selection of an add-on of the plurality of add-ons, and associate the add-on of the plurality of add-ons with the API, wherein the client libraries areutilized by users of the management system to consume the API, and wherein the processing system being configured to automatically generate the plurality of client libraries includes being configured to bring the client libraries into existence, and topublish the API via an online platform. 28. A management system comprising: means for receiving a text-based search query indicating API specific search criteria; means for searching a categorized API data store using the API specific search criteria; means for providing one ormore APIs that match the API specific search criteria via an online platform; means for providing a plurality of add-ons, wherein each add-on of the plurality of add-ons provides functionality in addition to an API of the one or more APIs; means forreceiving a selection of a first API of the one or more APIs that match the API specific search criteria responsive to providing the one or more APIs; means for receiving an indication of a selection of an add-on of the plurality of add-ons; means forassociating the add-on of the plurality of add-ons with the first API; means for automatically generating a plurality of client libraries based on user-generated parameters associated with the first API, and based on a standard description formatassociated with the first API; means for providing the plurality of client libraries associated with the first API responsive to receiving the selection of the first API; means for receiving a selection of a first client library of the plurality ofclient libraries associated with the first API; and means for providing the first API via the online platform. 29. A method comprising: receiving, at a management system, user-generated parameters including any of an applications programming interface (API) name, an API tag, an API version, an public/private setting for an API, a description of an API,or a description of a version of an API; configuring, at the management system, a proxy for providing secure communications between an API server and a client to enable the client to securely consume the API; generating, at the management system, aplurality of client libraries based on the user-generated parameters, wherein the client libraries are utilized by users of the management system to consume the API, and wherein generating the plurality of client libraries includes bringing the clientlibraries into existence; providing, by the management system, a selection of a plurality of add-ons to the client, wherein each add-on of the plurality of add-ons provides additional functionality to the API; receiving, at the management system andfrom the client, an indication of a selection of a particular add-on of the plurality of add-ons; associating, at the management system, the particular add-on with the API to provide additional functionality to the API; receiving, at the managementsystem, a request to publish the API; and publishing, at the management system, the API via an online platform. Description BACKGROUND Application programming interfaces (APIs) are specifications intended to be used as interfaces by software components to communicate with each other. For example, APIs can include specifications for routines, data structures, object classes,and variables. An API specification can take many forms, including an International Standard such as POSIX, vendor documentation such as the Microsoft Windows API, and/or the libraries of a programming language (e.g., Standard Template Library in C++ orJava API). Cloud-based (or simply cloud) APIs are a specific type of API that are used to build applications in the cloud computing market. Cloud APIs typically allow software to request data and computations from one or more services through a direct orindirect interface and most commonly expose their features via REST and/or SOAP. For example, vendor specific and cross-platform APIs can be made available for specific functions. Cross-platform interfaces typically have the advantage of allowingapplications to access services from multiple providers without rewriting, but may have less functionality or other limitations in comparison to vendor-specific solutions. Cloud-based APIs have become powerful tools that services, components, and devices routinely rely on and utilize. Unfortunately, there are several issues related to use and development of APIs. For example, it is often an arduous task for newcloud-based APIs to gain traction (or visibility) among developers. That is, when a cloud-based API developer designs a new API, making the world aware of the new API can be exceedingly difficult. Furthermore, application developers (i.e., API consumers) designing new applications or refining existing applications often cannot easily find, test, and/or otherwise download cloud-based APIs (i.e., the client libraries) because APIs arecurrently not easily searchable and, if an appropriate API is found, it is not documented or otherwise defined in a standardized fashion. Consequently, application developers may have to download many APIs before they eventually find an appropriate APIand, even then, usability and/or reliability of the API can be an issue.SUMMARY Systems and methods for facilitating distribution and consumption of APIs in a social cloud-based hub (or marketplace) are described herein. The social cloud-based API hub overcomes problems of the prior art by enabling users (i.e., APIconsumers) to access (e.g., search and/or otherwise utilize or consume) APIs that other users (i.e., API developers) submit to the social API hub in a standardized manner. The API consumers can test the APIs in the cloud without downloading the APIand/or writing any additional code prior to consuming the API. Further, the systems and methods provide API developers with the ability to wrap APIs submitted to the hub in a standard description format and add one or more add-ons on top of the existingAPI infrastructure. The add-ons can provide additional functionality to an API without requiring API developers to write any additional code. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 depicts a block diagram of an online environment suitable for facilitating distribution and consumption of APIs in a social cloud-based hub. FIG. 2 depicts a block diagram illustrating the components of a hub server suitable for facilitating distribution and consumption of APIs in a social cloud-based hub. FIG. 3 depicts a flow diagram illustrating an example process for facilitating distribution of APIs in a social cloud-based hub. FIG. 4 depicts a flow diagram illustrating an example process for facilitating consumption of APIs in a social cloud-based hub. FIG. 5 depicts a signaling diagram that illustrates representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API in a social cloud-based hub. FIG. 6A depicts a signaling diagram that illustrates representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API in a social cloud-based hub. FIG. 6B depicts a signaling diagram that illustrates representative messaging used by a client application, an on-premise proxy, and an API server to facilitate consumption of an API in a social cloud-based hub. FIG. 6C depicts a signaling diagram that illustrates representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API with a billing add-on in a social cloud-based hub. FIG. 7 depicts an example illustrating code representing an add-on that is configured to be loaded at run time for use in a social cloud-based hub. FIG. 8 depicts a block diagram illustrating an example programmable API proxy for use with a message broker and one or more add-on workers in a social cloud-based hub. FIG. 9 illustrates an example user interface depicting a homepage or front page of a social cloud-based hub. FIG. 10 illustrates an example user interface depicting API search results in a social cloud-based hub. FIGS. 11A-C illustrate an example user interface depicting an API profile page for use in a social cloud-based hub. FIG. 12 illustrates an example user interface depicting an API profile page for use in a social cloud-based hub. FIG. 13 illustrates an example user interface depicting a user homepage for use in a social cloud-based hub. FIG. 14 illustrates an example user interface depicting a user homepage for use in a social cloud-based hub. FIG. 15 illustrates an example user interface depicting a user homepage for use in a social cloud-based hub. FIG. 16 illustrates an example user interface depicting a user homepage for use in a social cloud-based hub. FIG. 17 illustrates an example user interface depicting an API profile administrator page for use in a social cloud-based hub. FIG. 18 illustrates an example user interface depicting an API profile administrator page for use in a social cloud-based hub. FIG. 19 illustrates an example user interface depicting an API profile administrator page for use in a social cloud-based hub. FIG. 20 illustrates an example user interface depicting an API profile administrator page for use in a social cloud-based hub. FIG. 21 depicts a diagrammatic representation of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.DETAILED DESCRIPTION The following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known orconventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure can be, but not necessarily are, references to the same embodiment; and, such references mean at least oneof the embodiments. Reference in this specification to ""one embodiment"" or ""an embodiment"" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Theappearances of the phrase ""in one embodiment"" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, variousfeatures are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments. The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Certain terms that are used to describe the disclosure arediscussed below, or elsewhere in the specification, to provide additional guidance to the practitioner regarding the description of the disclosure. For convenience, certain terms may be highlighted, for example using italics and/or quotation marks. Theuse of highlighting has no influence on the scope and meaning of a term; the scope and meaning of a term is the same, in the same context, whether or not it is highlighted. It will be appreciated that same thing can be said in more than one way. Consequently, alternative language and synonyms may be used for any one or more of the terms discussed herein, nor is any special significance to be placed upon whether or not a term is elaborated or discussed herein. Synonyms for certain termsare provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any terms discussed herein is illustrative only, and is not intended to further limitthe scope and meaning of the disclosure or of any exemplified term. Likewise, the disclosure is not limited to various embodiments given in this specification. Without intent to further limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles may be usedin the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in theart to which this disclosure pertains. In the case of conflict, the present document, including definitions will control. Embodiments of the present disclosure include systems, methods, and a machine readable medium for distributing, monetizing, managing and consuming cloud APIs. The systems, methods, and a machine readable medium facilitate distribution andconsumption of APIs in a social marketplace or hub. The social API hub enables users (i.e., API consumers) to access (e.g., discover, test, and/or otherwise utilize or consume) APIs that other users (i.e., API developers) submit to the hub in astandardized manner. In one embodiment, a cloud API hub (also referred to as a ""marketplace"" herein; although, as will be described below, some APIs in the hub may not be available for public consumption) is described that facilitates discovering, documenting,monetizing, and consuming APIs. The cloud API hub allows users (i.e., API developers) to post/publish or otherwise distribute an API in the cloud so that third-party developers can use and improve on it. The cloud API hub auto-generates libraries inmultiple languages providing for universal or near-universal access to the API. The auto-generated client libraries can include, among others, Bash, Ruby, Python, PHP, Node.js, C#, Java, and Objective-C. The hub allows users (i.e., API consumers) toconsume APIs from any kind of source API server. In one embodiment, users (i.e., API developers) can wrap up APIs submitted to the hub in a standard description format and add various add-ons (e.g., a billing system, authentication system, etc.) on top of an existing API infrastructure inorder to provide additional functionality on top of the existing API functionality. The add-ons can be selected and added without requiring the API developers to perform any additional coding steps. A billing add-on, for example, allows users to createpublic and private billing plans for premium APIs. Additionally, with minimal server-side configuration, a user can configure quotas on custom objects, which provides for a granular control of billing API consumers. In one embodiment, APIs can be easily documented in a standardized manner via an embedded editing interface graphical user interface (GUI). The documentation is then auto-generated and presented to developers so that they can understand andconsume the API. Alternatively or additionally, an API can be documented via standard XML. In one embodiment, users can post and/or publish their API or updates (or hacks) to their or others APIs in order to gain instant visibility for the API from an environment (i.e., the cloud-based hub) where developers are ready to consume theAPIs. API developers can earn money for posting (or otherwise publishing) an API and selling the API. Thus, the systems and methods provide for a virtual central repository with robust, easy to use, and well-documented cloud APIs. Environment FIG. 1 depicts a block diagram of example environment 100 suitable for facilitating distribution and consumption of APIs in a social hub. The example environment 100 includes a plurality of API developers 105A-N operating client devices 102A-N,a plurality of API consumers 115 operating client devices 112A-N, a plurality of application consumers 125A-N operating client devices 122A-N, a plurality of API servers 130A-N, a management (or hub) infrastructure 140, and a network 150. Alternativeconfigurations are possible. As shown, the management (hub) infrastructure 140 includes management (hub) server 141, API data store 142, and proxy 145. The API data store 142 and/or the proxy 145 can be distributed (physically distributed and/or functionally distributed),in some embodiments such as, for example when the proxy is installed at or near the API server 130 (i.e., proxy-on-premise). Additionally, although shown separately, it is appreciated that an API developer can also be an API consumer and/or anapplication consumer of other APIs in the hub. The management (hub) server 141 is configured to communicate with client devices 102A-N, 112A-N, and 122A-N, and API servers 130A-N for facilitating distribution and consumption of APIs in the cloud-based social hub. For example, an APIdeveloper 105 can interact with the management (hub) server 141 via a client device 112 in order to distribute and/or monetize an API (not shown) that the API developer has developed. The management (hub) server 141 acts as a virtual cloud-basedsocial-infused central repository for the API so that application developers (i.e., API consumers) 115A-N can easily search and download APIs for consumption in and/or by their applications. The API servers 130A-N typically host the APIs locally. However, in some embodiments, the APIs may be hosted by the management (hub) infrastructure 140. In one embodiment, the management (hub) infrastructure 140 is entirely comprised of one or more management (hub) servers 141 which include one or moreproxies 145 and the API data store 142. As shown, API server 130 is configured in the proxy-on-premise configuration with proxy 135 installed locally. In this case, the proxy 135 (e.g., proxy server) may be utilized to act as a secure interface between clients and the API servers130. Clients can thus access the API server 130 directly. A more detailed example illustrating the concept of proxy-on-premise is shown and discussed with respect to FIG. 7B. The client devices 102A-N, 112A-N, and 122A-N are coupled to network 150. The client devices 102A-N, 112A-N and/or 122A-N can be any systems, devices, and/or any combination of devices/systems that are able to establish a connection withanother device, server and/or other system. The client devices 102A-N and 112A-N typically include respective user interfaces 110A-N. Although not shown, in some embodiments, the client devices 122A-N can include similar functionality. The userinterfaces 110A-N include one or more input devices and a display or other output functionalities to present data exchanged between the devices to a user. The user interfaces 110A-N can also include graphical user interfaces such as those examplesdiscussed with respect to FIGS. 9-20. The client devices can include, but are not limited to, a server desktop, a desktop computer, a computer cluster, a mobile computing device such as a notebook, a laptop computer, a handheld computer, a mobile phone,a smart phone, a PDA, a BlackBerry.TM. device, a Treo.TM., and/or an iPhone or Droid device, etc. The network 150 can be any collection of distinct networks operating wholly or partially in conjunction to provide connectivity to the client devices and hub server, and can appear as one or more networks to the serviced systems and devices. Inone embodiment, communications to and from the client devices 102A-N, 112A-N and 122A-N can be achieved by, an open network, such as the Internet, or a private network, such as an intranet and/or the extranet. The network 150, to which the clientdevices 112A-N and 122A-N and API servers 130A-N are coupled, can be a telephonic network, an open network, such as the Internet, or a private network, such as an intranet and/or the extranet. For example, the Internet can provide file transfer, remotelog in, email, news, RSS, and other services through any known or convenient protocol, such as, but not limited to the TCP/IP protocol, Open System Interconnections (OSI), FTP, UPnP, iSCSI, NSF, ISDN, PDH, RS-232, SDH, SONET, etc. The client devices 102A-N, 112A-N, and 122A-N and API servers 130A-N can be coupled to the network 150 (e.g., Internet) via a dial-up connection, a digital subscriber loop (DSL, ADSL), cable modem, wireless connections, and/or other types ofconnection. Thus, the client devices 102A-N, 112A-N, and 122A-N can communicate with remote servers (e.g., API servers 130A-N, hub servers, mail servers, instant messaging servers, etc.) that provide access to user interfaces of the World Wide Web via aweb browser, for example. API data store 142 can store information such as software, APIs, analytics, authentication information, user information, descriptive data, images, system information, drivers, and/or any other data items utilized by the management (hub) server141 for operation. In one embodiment, API data store 142 can be managed by a database management system (DBMS), for example but not limited to, Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, MySQL, FileMaker, etc. Databases 141-143 canbe implemented via object-oriented technology and/or via text files, and can be managed by a distributed database management system, an object-oriented database management system (OODBMS) (e.g., ConceptBase, FastDB Main Memory Database Management System,JDOlnstruments, ObjectDB, etc.), an object-relational database management system (ORDBMS) (e.g., Informix, OpenLink Virtuoso, VMDS, etc.), a file system, and/or any other convenient or known database management package. As shown, the API data store 142is coupled to management (hub) server 141. It is appreciated that, in some embodiments, API data store 142 may be coupled directly to network 150. FIG. 2 depicts a block diagram illustrating an example system 200 that facilitates distribution and consumption of APIs in an API hub. The system 200 includes management (hub) server 141 coupled to API data store 142. As shown, the management(hub) server 141 is the management (hub) server of FIG. 1, although alternative configurations are possible. The management (hub) server 141, although illustrated as comprised of distributed components (physically distributed and/or functionally distributed), could be implemented as a collective element. In some embodiments, some or all of themodules, and/or the functions represented by each of the modules, can be combined in any convenient or known manner. Furthermore, the functions represented by the modules and/or engines can be implemented individually or in any combination thereof,partially or wholly, in hardware, software, or a combination of hardware and software. In the example of FIG. 2, the management (hub) server 141 includes a network interface 205, a communication module 208, an administration module 210, a web server module 220, a social module 230, an API consumer interface module 240, an APIdeveloper interface module 250, a proxy module 260, and an API add-on module 270. Additional or fewer modules can be included. The management (hub) server 141 can be communicatively coupled to the API data store 142, as illustrated in FIG. 2. In some embodiments, the API data store 142 is partially or wholly internal to the management (hub) server 141. In otherembodiments, the API data store 142 is coupled to the management (hub) server 141 over network 150. In one or more embodiments, the API data store 142 is a distributed database. In the example of FIG. 2, the network interface 205 can be one or more networking devices that enable the management (hub) server 141 to mediate data in a network with an entity that is external to the server, through any known and/or convenientcommunications protocol supported by the host and the external entity. The network interface 205 can include one or more of a network adaptor card, a wireless network interface card, a router, an access point, a wireless router, a switch, a multilayerswitch, a protocol converter, a gateway, a bridge, a bridge router, a hub, a digital media receiver, and/or a repeater. In the example of FIG. 2, the management (hub) server 141 includes the communications module 208 communicatively coupled to the network interface 205 to manage a communication session over a plurality of communications protocols. In oneembodiment, the communications module 208 receives data (e.g., audio data, textual data, audio files, etc.), information, commands, requests (e.g., text and/or audio-based), and/or text-based messages over a network. Since the communications module 208is typically compatible with receiving and/or interpreting data originating from various communication protocols, the communications module 208 is able to establish parallel and/or serial communication sessions with users of remote client devices,merchant POS devices, payment systems, advertisers, web servers, and data miners. One embodiment of the management (hub) server 141 includes an administration module 210. The administration module 210 can be any combination of software agents and/or hardware components able to manage and register users of management (hub)server 141. The administration module 210 includes a registration engine 212 and an authentication engine 214. In one embodiment, the registration engine 212 is configured to register new users including API developers and/or API consumers. This process may involve creating new accounts with the management (hub) server 141. In one embodiment, duringthe registration process, a user can provide login credential for the various social networking sites that they would like to log-in to or from, and to which the user would like to provide status updates from the management (hub) server 141. Theauthentication engine 214 is configured to authenticate the hub users as they access the management (hub) server 141 from a variety of devices. In some embodiments, authentication occurs by associating a user's username and password with an existinguser account and/or associating an affiliate POS device with an existing affiliate account and/or associating an advertiser's username and password with an existing advertiser account. Unauthorized users can be directed to register with the system. One embodiment of the management (hub) server 141 includes a web server module 220. The web server module 220 can be any combination of software agents and/or hardware components able to interact with users that have logged in or otherwiseaccessed or interacted with the management (hub) server 141. In one embodiment, the web server module 220 provides access to API developers and API consumers via an online platform (e.g., web interface). The web server module 220 presents or otherwiseprovides access to the virtual cloud-based social-infused central repository for APIs that is managed by the management (hub) server 141. For example, graphical interfaces such as those described in FIGS. 9-20 may be provided and/or otherwise served toclient devices by the web server module 220. One embodiment of the management (hub) server 141 includes a social module 230. The social module 230 can be any combination of software agents and/or hardware components able to provide users (e.g., API consumers and API developers) withsocial components. For example, each API can include a chat area, an issues area, notification areas, etc., that provides indications about the users that hack on (e.g., aid in the development of) and/or consume specific APIs. The chat area can allowusers to discuss, for example, useful aspects of an API. Similarly, the issues area can alert users as to specific bugs and/or bug fixes or workarounds. The indications about the users that hack and/or otherwise utilize particular APIs is aninteresting social aspect that allows users to see which APIs other users are consuming. The social module 230 can also provide private and/or public messaging services, boards for questions related to specific APIs or general APIs, monitoringinformation about general and/or specific APIs such as, for example, ratings of APIs, reviews of APIs, etc. Additionally, the social module 230 may provide an area to raise tickets (e.g., to fix bugs in APIs), etc. The social module 230 also allows users to maintain a personal profile. An example personal profile is shown in FIG. 15. The user may link Facebook, LinkedIn, GitHub, and/or Twitter accounts to their profile in order to stay connected withother developers and friends and to keep apprised of the latest APIs that their friends are using, etc. Users can also follow one another within the API hub system. The users can also have auto-generated reputations attached to their personal profilesso that developers can literally know ""who's who"" among the API community. One embodiment of the management (hub) server 141 includes an API consumer interface module 240. The API consumer interface module 240 can be any combination of software agents and/or hardware components able to allow API consumers to search,test, and/or otherwise access the API in the hub. The API consumer interface module 240 includes an API search engine 242, an embedded test engine 244, and a token generation/authentication engine 246. In one embodiment, the API search engine 242 is configured to receive and process search queries received from users (i.e., API consumers). For example, when a search query is received, the API search engine 242 searches the categorized APIdata store 142 based on the search query, and returns one or more APIs that match the query. The query can be, for example, a text based search inquiry. In one embodiment, the embedded test engine 244 allows a user to test the API in the cloud prior toactual use and/or integration in an application. Advantageously, the API can be tested in the cloud (e.g., online) without writing any code. The token generation/authentication engine 246 generates authentication tokens for consuming clients to consumeAPIs. This process is discussed is greater detail with reference to FIG. 5, but generally the tokens provide for additional security in some embodiments. One embodiment of the management (hub) server 141 includes an API developer interface module 250. The API developer interface module 250 can be any combination of software agents and/or hardware components able to interface with an APIdeveloper to publish an API. The API developer interface module 250 includes a proxy configuration engine 252, a client library generation engine 254, a categorization engine 256, and an API publishing engine 258. In one embodiment, in order to provide secure communications between and API server and clients (e.g., API consumers), the proxy configuration engine 252 configures a proxy such as, for example, proxy 145 of FIG. 1. The API server serves theAPI. The API servers can be local or remote to the management (hub) server 140. In one embodiment, the client library generation engine 254 is configured to automatically generate a plurality of client libraries based on user-generated parametersassociated with the API. The user-generated parameters are provided by an API developer prior to publishing the API. Once published, the API is available for use by API consumers in the social hub. In one embodiment, the API publishing engine 258publishes the API in the social hub (i.e., makes the API available for download and/or consumption by API consumers via the online platform). One embodiment of the management (hub) server 141 includes a proxy module 260. The proxy module 260 can be any combination of software agents and/or hardware components able to perform proxy operations as described herein. For example, in oneembodiment, the proxy provides secure communications between the API and clients (e.g., API consumers). Like other modules described with respect to the management (hub) server 141, in some embodiments, the proxy module 260 may be external to themanagement (hub) server 141. In one embodiment, the proxy is programmable via either or both of the proxy module 260 or the proxy configuration engine 252. Programmable proxies are easily expandable with more features and/or connectablity with third-party services. With aprogrammable proxy, add-ons can modify an API request at any point in the lifecycle of the request, block execution of the request (e.g., through authentication), read and modify the response from an API server, etc. As discussed, the add-ons can beinstalled locally (i.e., proxy-on-site) or remotely (i.e., proxy module 260 of FIG. 2 or proxy 145 of FIG. 1). If the add-ons are installed remotely, the customer need not work directly with them because the proxy auto-configures by automaticallydownloading the required information from the remote servers and activating the appropriate add-ons during the execution. The proxy can identify the API by analyzing the requested URL/domain name/DNS information (e.g., CNAME entry). Example using theproxy are discussed in greater detail with respect to FIGS. 6-8. One embodiment of the management (hub) server 141 includes an API add-on module 270. The API add-on module 270 can be any combination of software agents and/or hardware components able to provide API developers a plurality of add-ons forincluding with a published API. The API add-on module includes an API add-on library 272 and an API add-on UF engine 274. In one embodiment, the API add-on library 272 stores a plurality of add-ons that a developer can select to include on top of anAPI. For example, the add-on library 272 can include various add-ons that can be included with an API for consumption in the hub. For example, the add-on library 272 can include billing add-ons, analytics add-ons, authentication add-ons, etc. Theadd-on is typically a piece of code that connects a proxy with a third-party service or extends the proxy functionalities. As will be discussed below in greater detail, the add-ons can be executed during the lifecycle of the API request or standalone. In one embodiment, the API add-on I/F engine 274 can interface with an API developer to wrap one or more add-ons around an API. FIG. 3 depicts a flow diagram illustrating an example process 300 for facilitating distribution of APIs in a social cloud-based hub, according to an embodiment. More specifically, example process 300 illustrates an example of a user (i.e., APIdeveloper) publishing an API to a management (hub) server. In one embodiment, the management (or hub) system performs example process 300. To begin, the management server receives user (i.e., API developer) login information or credentials. In some embodiments, the login information can include a customer identification (ID)/password combination. In process 310, the managementserver receives user-generated parameters describing functionality associated with an API that the user wants to publish in the social cloud-based hub. The parameters can include definitions of API name, tags, versions, public/private (i.e., public APIsare indexed), descriptions of the API and/or versions of the API, various target information, and various proxy information. Private APIs can be download by only a selected group of API developers. Target information can define target URLs and/or services that the API invokes, the interface structure for the API, operations of the API, etc. The targets can be defined as production and/or sandbox (e.g., development). The structure of anAPI can be defined such as, for example, a SOAP or REST service and profile information such as input/output requirements (e.g., XML/JSON, etc.). The operations such as LIST, READ, ADD, etc. can each have an associated method (e.g., GET, POST) and anassociated path. The proxy definition provides information about how the API looks, what context prefixes and paths it requires, etc. In process 312, the management system configures a proxy for providing secure communications between an API server and client (e.g., application consumers). In process 314, the management server automatically generates a plurality of clientlibraries based on the user-generated parameters. The client libraries are utilized by one or more API consumers. In process 316, the user is provided a selection of add-on to wrap around their API. As discussed, the add-ons can provide additionalfunctionality to APIs. In process 318, the management system determines whether any add-ons are selected and, if so, in process 320, wraps the one or more selected add-ons on top of the existing API infrastructure. In process 322, after configuration is completed, the management server determines whether or not the user wants to publish the API. If so, in process 324, the management server publishes the API in the online platform. Otherwise, the APIdeveloper can go back and make additional changes quit and cancel the API publication process. FIG. 4 depicts a flow diagram illustrating an example process 400 for facilitating consumption of APIs in a social cloud-based hub, according to an embodiment. More specifically, example process 400 illustrates an example of a client (i.e., APIconsumer) consuming or otherwise obtaining an API using the management (hub) server. In one embodiment, the management (hub) server performs example process 400. To begin, the management server receives user (i.e., API developer) login information or credentials. In some embodiments, the login information can include a customer identification (ID)/password combination. In process 410, the managementserver receives a text-based search query. For example, a client (i.e., API consumer) consuming or otherwise obtaining an API using the management (hub) server can enter a text-based search string into the search interface. An example search interfaceis shown and discussed in greater detail with reference to FIG. 9. In process 412, the management server, searches a categorized (or indexed) API data store based on the query information and, in process 414, provides one or more APIs that match the search criteria. An example search results page is shown anddiscussed in greater detail with respect to FIG. 10. In process 416, the management server determines if the API consumer has made a selection of an API. If so, in process 418, the management server provides (or displays) an API profile associated with the API to the user. An example API profileis shown and discussed in greater detail with respect to FIGS. 11A-C and 12. In process 420, the management server determines whether the API consumer wishes to test the API on the hub and, if so, in process 422 the management server tests the APIwithout requiring the user to write any additional code. In one embodiment, the test interface is embedded in the graphical user interface as illustrated in FIGS. 11A-C. In process 424, the management server determines if the API consumer wants to download the API. If so, in process 426, the management server determines if the API consumer wants to download the API with the client libraries. If so, in process428, the management server provides the auto-generates client libraries associated with the selected API to the user. In process 430, the management server determine if the API consumer has selected one of the API libraries. If so, in process 422, themanagement server provides (downloads) the selected API to the API consumer via the online platform. Programmable API Proxy FIG. 5 depicts a signaling diagram 500 that illustrates representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API in a social cloud-based hub, accordingly an embodiment. The clientsystem, management server, and API server could be an API consumer device 122, management (hub) server 140, and API server 130 of FIG. 1, respectively; although alternative configurations are possible. Add-ons, as discussed herein, can be loaded at any time during execution of the proxy (not necessarily at startup). It is appreciated that any of the methods of loading the add-ons described herein can co-exist. In one embodiment, add-ons canexecute (or work) in two modes. In one mode, the add-on works during the lifecycle of an API request (e.g., when certain events are triggered, like ""onStart,"" ""onEnd,"" etc.). In a standalone mode, the add-on is not triggered by an API request butrather some other event (e.g., a timer that invokes add-on every thirty seconds). The example of FIG. 5 illustrates an example of the former mode (i.e., workflow of an add-on tied with the lifecycle of the request). To begin, a client makes an API request. The proxy identifies the API request, and loads the APIs installed add-ons if not already completed (e.g., either locally or remotely). The proxy then triggers one or more events that activate theinstalled add-ons. If the add-ons do not block execution (an authentication may block an unauthorized request), the proxy forwards the request to the appropriate API server (API hub server). The proxy subsequently receives a response from the APIserver and triggers other events (e.g., ""onClose""). Lastly, a response is sent back to the client. In one embodiment, the management (hub) server and the entire API conforms to the design principles of Representational State Transfer (REST). In this case, methods to retrieve data from the management (hub) server require a GET request, whilemethods to submit, change, or destroy data require a POST, PUT, or DELETE. The API supports JavaScript Object Notation (JSON) data. Because the API can be a REST API that runs over HTTP, this also means that the API can be accessed by any applicationor device that has an internet connection and can speak HTTP. A developer can create any APIs. For example, apart from listing services, a developer could create an API for (by way of example, and not limitation): audio services, document conversion, email services, financial services, geolocalizationservices, graph generation, image services, news aggregators, SMS services, statistical services, text-to-speech services, translation services, video services, whois services, wrappers around existing services (e.g., Facebook, Twitter, etc.), etc. FIGS. 6A and 6B depict signaling diagrams 600A and 600B, respectively, that illustrate representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API in a social cloud-based hub. FIG. 6Aillustrates an example whereby the proxy is installed remotely (remote to the API server). FIG. 6B illustrates an example whereby the proxy is installed locally (downloaded and installed on the API provider infrastructure--also called""proxy-on-premise""). In process 1, a client makes an HTTP request to the proxy. In process 2, the proxy executes the installed add-ons before the request is proxied to the API. In process 3, the request is forwarded to the final API server. In process 4, the APIreturns a response. In process 5, the proxy executes the installed add-ons after the request has been proxied to the API, and before returning the response to the client. Lastly, in process 6, the response is returned to the client. Some add-ons are executed before the request is proxied (at process 2). Others are executed after the request has been proxied (at process 5). Yet other add-ons are executed both at process 2 and process 5. For example, the Authenticationadd-on that validates the client, is executed before the request is proxied because if the client is not authenticated then an error is returned and the connection is closed immediately. The billing add-on is executed before and after. That is, thebilling add-on is executed before because it needs to check if the client is subscribed to a billing plan of the API (if not, close connection and return error) and after, because it needs to parse the API server response to set the billing usage for theclient. FIG. 6C discusses a billing add-on in greater detail. In the examples of FIG. 6A and 6B the programmable API proxy is an HTTP(s) proxy that can be put in front of an API of any kind. As shown, the programmable API proxy can be utilized in the cloud and/or can be installed in a customer'sinfrastructure (i.e., a customer is an API developer or owner of an API that has been published in the hub). The programmable API proxy may be proxy 145 of FIG. 1, although alternative configurations are possible. In one embodiment, the programmable API proxy can be expanded with one or more add-ons. For example, an add-on may include, but is not limited to, a billing add-on, an analytics add-on, an authentication add-on, etc. An example billing add-onis discussed in greater detail with respect to FIG. 6C. In this context, an add-on is a snippet or piece of computer programmable code that connects the proxy with a third-party service and/or otherwise extends the proxy functionalities. The add-on canbe executed during the lifecycle of the API request or standalone. More specifically, an add-on can be: 1) a connector to a service not included into the proxy; 2) an extension to the proxy that executes computations on the API request (e.g., a formattransformation from XML to JSON). Add-ons can be installed locally and/or remotely. If an add-on is installed remotely, and the proxy serves more than one API server, then the installed add-on list is downloaded from the remote server. In this case, the installed add-on listis downloaded from the remote server so that only those add-ons that the customer has selected are executed. FIG. 6C depicts a signaling diagram 600C that illustrates representative messaging used by a client application, a proxy, and an API server to facilitate consumption of an API with a billing add-on in a social cloud-based hub, according to anembodiment. Although shown as a remote proxy, it is appreciated that the billing add-on can also be configured as a proxy-on-premise in other embodiments. In process 1, a client makes an HTTP request to the proxy. In process 2, the billing add-on checks if the client is subscribed to an API billing plan (the developer that build the client can subscribe to billing plans from the management (hub)server in the API profile. In process 2.1, the management server returns an error to the client and closes the connection with the client if the client is not subscribed to the billing plan. In process 3, the request is forwarded to the final APIserver. In process 4, the API returns a response. In process 5, the billing add-on checks for specific information created by the API (e.g., a specific header) that is appended to the response. The billing add-on also allows the API to instruct thebilling add-on to set a customer usage amount for the request. Lastly, in process 6, the response is returned to the client. When an API provider adds the billing add-on for his API, he can create subscription plans that the developers who build the clients can subscribe to. The billing plans created by the API provider can include the notion of ""Custom Objects,"" forexample. The plans can charge the user upon the amount of ""Statuses Classified."" The proxy, which just proxies the HTTP request, may not know what that request actually does. Thus, for the user to be actually charged, the system needs to know how many""Statuses Classified"" requests were made. The proxy can't increment by itself the usage of the ""Statuses Classified"" counter associated to the user, because it doesn't know what the request does and how many ""Statuses Classified"" were consumed duringthe request. To indicate to the proxy, and more specifically, to the Billing Add-on, how many billing objects were consumed by the request (e.g., ""Statuses Classified""), the API provider can either choose to: 1) Configure the billing add-on to automatically increment by one unit the billing objects. This increments every billing object specified without assuring that this is actually true. Because the proxy and the billing add-on don't know whatthe request really does and how many billing objects were consumed in the request, it will just increment by one the usage. 2) Return an additional header that tells the billing add-on to increment the usage of the custom billing object by a specific amount. For example, the API provider can return the following header: ""X-Mashape-Billing: statuses classified=5.""This header tells the billing add-on that the request made by the client consumed five units of ""Statuses Classified."" In this example, the header name and value are arbitrary. Any header name and a header value could potentially be used. The name ofthe billing object is also arbitrary and set by the API provider. For example, an API may not have a ""Status Classified"" object, but could have ""DETECT"" and/or ""RECOGNIZE"" billing objects. FIG. 7 depicts an example illustrating an add-on configured to be loaded at run time. The example add-on of FIG. 7 is written in JavaScript and executed by node.js (http://nodejs.org/), that defines two functions executed when the ""onStart"" and""onClose"" event are triggered by the proxy. The proxy has the task of loading and executing the add-on. Depending on the scenario, the proxy can load and invoke add-ons in a variety of ways. For example, the add-on can be bundled with the proxy, loaded or invoked at runtime, and/or the add-on can be a separate application (also called a ""worker"")that is executed when certain conditions are met. When the add-on is loaded or invoked at runtime, the add-on can be loaded from a file and/or the source code of the add-on can be download from a third-party server and stored in a file and/or executedin memory. When the add-on is a separate ""worker"" application that is executed when certain conditions are met, the add-on can be a server that listens on a port and is invoked by the proxy, and/or an application that processes a message queue that ispopulated by the proxy. The add-on is typically bundled with the proxy or loaded or invoked at runtime when the proxy is run on high CPU machines and when requirements exist to reduce the complexity of the infrastructure. The add-on can be a separate ""worker""application when a requirement exists to have separate machines to better scale the whole architecture. FIG. 8 depicts a block diagram illustrating an example programmable API proxy for use with a message broker and one or more add-on workers in a social cloud-based hub, according to an embodiment. More specifically, FIG. 8 illustrates an examplestandalone add-on. In the example of FIG. 8, the proxy, rather than triggering events that are executed by a piece of code loaded at run-time, pushes or otherwise sends a message to a message broker. The message broker notifies the add-on workers. Theadd-on workers process the messages asynchronously and execute the desired action(s). The architecture illustrated with respect to FIG. 8 is highly scalable. For example, when a plurality of requests are received by the proxy, the system administrator can simply add an unlimited number of ""workers"" to scale up the system. The""workers"" can be in-memory processes or separate servers, and the message broker can be installed in the proxy to avoid having another separate process, or server, running. User Interface Examples The user interfaces of FIGS. 9-20 are generally self-explanatory based on the above detailed description, but some details will now be provided. The user interfaces of FIGS. 9-20 are generally discussed with respect to a social API hub forfacilitating distribution of APIs. Referring first to FIG. 9 which depicts an example interface 900, according to an embodiment. More specifically, example interface 900 depicts a management (or hub) server front page or homepage. The example interface 900 includes a searcharea or search bar 902, which is provided to potential API consumers, a login button 904, and a new user button 906. The search area 902 allows potential API consumers searching for specific APIs to enter text-based queries that can indicate a type ofAPI that the user is searching for, specific functionality associated with an API the user is searching for, and/or the name of an API that the user is searching for. The user is then provided with search results, such as those shown in FIG. 10, afterselecting the ""search"" button. As discussed above, in one embodiment, the management (hub) server searches the API data store to identify those APIs that match the search criteria. The example interface 900 also includes various other buttons fordocumentation, support, etc. FIG. 10 depicts an example search results interface 1000, according to an embodiment. In the example of FIG. 10, a potential API consumer has searched for APIs by entering a text-based search string into the search bar. The example interface1000 includes a search results area 1002 and a search by category area 1006. The search by category area includes various categories that a user can browse or follow. Users can follow a category by selecting the follow category button 1008 that isassociated with a particular category. The search results area 1002 indicates various APIs that match the search criteria (e.g., the text-based search string). Each of the APIs that match the search criteria can include an associated API category in an API category area 1004 and ahacker information area 1006, among other information, displayed. The hacker information area 1006 provides social benefit as a potential API consumer can see which hacker (i.e., developers and/or users) hacks on, and/or makes modifications to, thatAPI. More hackers can indicate a better API that is less prone to bugs and more likely to be quickly updated. As discussed above, hackers can, in some embodiments, update, modify, and/or otherwise edit APIs in some instances. Additionally, thesehackers may leave useful comments and or interact with one another in order to speed up the development process and make it more enjoyable through social interaction. Additionally, in the search results example interface 1000, the number of methods in the API can be illustrated in addition to brief descriptions, pricing information, follow API buttons, etc. Many APIs are free or freemium (i.e.,have free andpaid aspects). FIGS. 11A-C illustrate an example user interface 1100 depicting an API profile page for use in a social cloud-based hub, according to an embodiment. An API profile interface may be presented if, for example, an API has been selected from thesearch results in order to show more detailed information about the selected API. The API profile page 1100 includes an API documentation tab 1102, an API pricing tab 1104, a more add-ons tab 1108, and a report issue button 1106. In this example, the more add-ons tab 1108 illustrates a tab that can represent one or moreadditional add-ons. It is appreciated that there may be another tab for each additional add-on. As shown, the API documentation tab 1102 is selected causing the documentation pane 1120 to be displayed. The documentation pane 1120 illustrates variousinformation about the selected API. Additionally, the documentation pane 1120 includes an embedded API test area 1112. The embedded API test area 1112 is provided to allow a potential API consumer to test the API in the cloud-based system or hub prior to downloading and/orotherwise committing to the API. As discussed above, the management system provides the ability to test the API online or in the cloud-based environment without writing code. FIGS. 11B and 11C illustrate more detail about the embedded API test area1112. For example, within the embedded API test area 1112, a response status pane can include a response body test tab 1114 and a response headers tab 1116. Other tabs (not shown) are also possible. FIG. 12 illustrates an example user interface depicting the API profile page 1100 for use in a social cloud-based hub when the API pricing tab 1104 is selected. More specifically, when the API pricing tab 1104 is selected, the pricing pane 1202is illustrated. The pricing pane 1202 illustrates various pricing information for the particular API. As discussed, many APIs are free or freemium (i.e., have free and paid aspects); however, others require payment (e.g., based on yearly, monthly,weekly, query access). From the API profile page 1100, a user can select to download an API for integration into an application. The selected API can be downloaded (for later consumption) via a variety of auto-generated client libraries such as, for example, Bash,Ruby, Python, PHP, Node.js, C#, Java, and Objective-C. Additionally, information related to the privacy of the API, whether the API is running, the reliability of the API, the cost of the API, and the rate of the API can also displayed. FIG. 13 illustrates an example user interface 1300 depicting a user homepage for use in a social cloud-based hub, according to an embodiment. As shown, the user homepage 1300 includes an add API button 1302. When selected, the API button 1302allows a user to add an API for distribution in the hub. The user homepage 1300 also includes a dashboard tab 1310, a consumer console tab 1304, an inbox tab 1306, and a user account tab 1308. As shown, the dashboard tab 1310 is selected such that a dashboard pane 1312 is illustrated. The dashboardpane 1312 shows activities related to APIs the user is following, APIs the user has created, APIs the user has consumed, etc. Activities can include any event related to an API such as, for example, publishing an API or updating an API. The userhomepage also includes an API use information area 1314 that illustrates information related to use of APIs by the user such as, for example, APIs created and APIs consumed. FIG. 14 illustrates an example of user homepage 1300 where the consumer console tab is selected such that the consumer console pane 1402 is displayed. The consumer console pane 1402 can graphically illustrate various statistics related to APIsassociated with the user. This can include usage and subscription statistics (as shown). FIG. 15 illustrates an example user interface depicting a user homepage (or profile page) 1500 for use in a social cloud-based hub. In addition to other information, API information related to the user, API activity associated with the user,etc. can be displayed. FIG. 16 illustrates an example of user homepage 1300 wherein the add API button 1302 is selected. It is appreciated that various user interface pages include an add API button and the example of FIG. 16 is representative of any of those pages. FIGS. 17-20 illustrate an example user interface depicting an API profile administrator page 1700 for use in a social cloud-based hub, according to an embodiment. As shown in FIG. 17, an overview tab is selected such that an overview pane 1702is displayed. Among other indicators, the overview pane 1702 can illustrate API activity and add-ons related to a specific API. In this example, information related to the API ""Image Pack"" is shown to the administrator (i.e., the API developer) of the""Image Pack"" API. FIG. 18 illustrates the API profile administrator page 1700 with the settings tab selected such that a settings pane 1802 is displayed. Among other information, the settings pane 1802 can illustrate generation information, proxy settings,firewall information, etc. FIG. 19 illustrates the API profile administrator page 1700 with the documentation tab selected such that a documentation pane 1902 is displayed. The documentation pane 1902 includes various information related to the API. An API developer canadd and/or modify this information, which is displayed to API consumers, at any time. FIG. 20 illustrates the API profile administrator page 1700 with the add-ons tab selected such that an adds-ons pane 2002 is displayed. The add-ons pane 2002 displays information related to the add-ons installed on top of the API. Among otherinformation the add-ons pane 2002 can illustrate API billing information, API permission information, etc. FIG. 21 shows a diagrammatic representation of a machine in the example form of a computer system 2100, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a client-servernetwork environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone or smart phone, a tablet computer, a personal computer, a webappliance, a point-of-sale device, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. While the machine-readable (storage) medium is shown in an exemplary embodiment to be a single medium, the term ""machine-readable (storage) medium"" should be taken to include a single medium or multiple media (a centralized or distributeddatabase, and/or associated caches and servers) that store the one or more sets of instructions. The term ""machine-readable medium"" or ""machine readable storage medium"" shall also be taken to include any medium that is capable of storing, encoding orcarrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. In general, the routines executed to implement the embodiments of the disclosure, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as""computer programs."" The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computerto perform operations to execute elements involving the various aspects of the disclosure. Moreover, while embodiments have been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments are capable of being distributed as a program product in avariety of forms, and that the disclosure applies equally regardless of the particular type of machine or computer-readable media used to actually effect the distribution. Further examples of machine or computer-readable media include, but are not limited to, recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., Compact DiskRead-Only Memory (CD ROMS), Digital Versatile Discs, (DVDs), etc.), among others, and transmission type media such as digital and analog communication links. Unless the context clearly requires otherwise, throughout the description and the claims, the words ""comprise,"" ""comprising,"" and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say,in the sense of ""including, but not limited to."" As used herein, the terms ""connected,"" ""coupled,"" or any variant thereof, means any connection or coupling, either direct or indirect, between two or more elements; the coupling of connection between theelements can be physical, logical, or a combination thereof. Additionally, the words ""herein,"" ""above,"" ""below,"" and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word ""or,"" in reference to a list of two or more items, covers allof the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list. The above detailed description of embodiments of the disclosure is not intended to be exhaustive or to limit the teachings to the precise form disclosed above. While specific embodiments of, and examples for, the disclosure are described abovefor illustrative purposes, various equivalent modifications are possible within the scope of the disclosure, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternativeembodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each ofthese processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed atdifferent times. Further any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges. The teachings of the disclosure provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various embodiments described above can be combined to provide further embodiments. Any patents and applications and other references noted above, including any that may be listed in accompanying filing papers, are incorporated herein by reference. Aspects of the disclosure can be modified, if necessary, to employ the systems,functions, and concepts of the various references described above to provide yet further embodiments of the disclosure. These and other changes can be made to the disclosure in light of the above Detailed Description. While the above description describes certain embodiments of the disclosure, and describes the best mode contemplated, no matter how detailed theabove appears in text, the teachings can be practiced in many ways. Details of the system may vary considerably in its implementation details, while still being encompassed by the subject matter disclosed herein. As noted above, particular terminologyused when describing certain features or aspects of the disclosure should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the disclosure with which thatterminology is associated. In general, the terms used in the following claims should not be construed to limit the disclosure to the specific embodiments disclosed in the specification, unless the above Detailed Description section explicitly definessuch terms. Accordingly, the actual scope of the disclosure encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the disclosure under the claims. While certain aspects of the disclosure are presented below in certain claim forms, the inventors contemplate the various aspects of the disclosure in any number of claim forms. For example, while only one aspect of the disclosure is recited asa means-plus-function claim under 35 U.S.C. .sctn.112, 6, other aspects may likewise be embodied as a means-plus-function claim, or in other forms, such as being embodied in a computer-readable medium. (Any claims intended to be treated under 35 U.S.C. .sctn.112, 6 will begin with the words ""means for."") Accordingly, the applicant reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the disclosure."
17|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=9&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Declarative approach to virtual network creation and operation|A network controller may receive a request from an application via an application programming interface (API), wherein the request comprises program codes written in a declarative programming language, and wherein the program codes describe at least some aspects of a virtual network (VN). The network controller may further parse the program codes into internal objects of the network controller, with the internal objects representing the aspects of the VN described by the program codes. The network controller may then manage the VN according to the internal objects translated from the program codes.|
18|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=29&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Balancing virtual machine loads|A method for balancing virtual machine loads is provided. The method comprises: monitoring load information of each of physical hosts and virtual machines operating on said physical hosts; calculating load index of each of said physical hosts and said virtual machines operating on said physical hosts respectively according to said load information; based on load index of each physical hosts, determining a source physical host on which any virtual machine needs to be migrated so as to reduce the load index of the source physical host; determining a target virtual machine to be migrated on the source physical host based on load index of each virtual machines on the source physical host and respective affinity factor indicating a degree of dependency of a virtual machine on a physical host on which it resides; and migrating the target virtual machine into a destination physical host different than the source physical host.|"1. A method for balancing virtual machine loads comprises: monitoring load information of each of physical hosts and virtual machines operating on the physical hosts; calculating a load index of each of the physical hosts and the virtual machines operating on the physical hosts respectively according to the load information; based on the load index of each of the physical hosts, determining a source physical host onwhich any virtual machine needs to be migrated so as to reduce the load index of the source physical host, wherein determining the source physical host comprises at least one of selecting a physical host with a largest load index as the source physicalhost, selecting a physical host with a load index larger than a first preset threshold as the source physical host, and selecting a physical host whose load index is always larger than the first preset threshold in a preset number of recent monitoringmeasurements; determining a target virtual machine to be migrated on the source physical host based on the load index of each of the virtual machines on the source physical host and respective affinity factor indicating a degree of dependency of avirtual machine on a physical host on which it resides; and migrating the target virtual machine into a destination physical host different than the source physical host. 2. The method according to claim 1, wherein the destination physical host is determined by at least one of selecting a physical host with a smallest load index as the destination physical host, selecting a physical host with a load indexsmaller than a second preset threshold as the destination physical host, and selecting a physical host whose load index is smallest and smaller than the second preset threshold as the destination physical host. 3. The method according to claim 1, wherein determining a target virtual machine to be migrated comprises: weighting the load index of each of the virtual machines on the source physical host according to a respective preset affinity factor ofeach of the virtual machines; and selecting a virtual machine having a largest weighted load index value as the target virtual machine to be migrated. 4. The method according to claim 1, wherein the monitoring the load information of each of the physical hosts and virtual machines operating on the physical hosts comprises: in monitoring each physical host, using a python script to remotelyexecute a relevant statistical command through a security shell (ssh) so as to obtain the load information of each physical host; and in monitoring each of the virtual machines operating on the physical hosts, using a python script to remotely execute arelevant command through the ssh so as to obtain the load information of the virtual machine from a corresponding process of the physical host in which the virtual machine resides, wherein the load information includes central processing unit (CPU)usage, memory usage and input/output(IO) throughput, and the relevant statistical command is determined according to running processes of the physical hosts. 5. The method according to claim 4, wherein the calculating the load index of each of the physical hosts and the virtual machines operating on the physical hosts respectively according to the load information comprises: determining an IOthroughput factor according to the IO throughput, and weighting the CPU usage, the memory usage and the IO throughput factor to calculate the load index. 6. The method according to claim 5, wherein the determining the IO throughput factor according to the IO throughput comprises: selecting a maximum IO throughput from monitored IO throughputs of all of the physical hosts, and calculating the IOthroughput factor of each physical host as a ratio of an IO throughput of the physical host to the maximum IO throughput; and selecting a maximum IO throughput from the monitored IO throughputs of all of the virtual machines on a physical host, andcalculating the IO throughput factor of each virtual machine on the physical host as a ratio of the IO throughput of the physical host to the maximum IO throughput selected from the monitored IO throughputs of all of the virtual machines on the physicalhost. 7. The method according to claim 1, further comprising when adding a new virtual machine: selecting a physical host with a smallest load index, and adding the new virtual machine onto the physical host. 8. An apparatus for balancing virtual machine loads comprising: a hardware processor; and a memory storing machine readable instructions that when executed by the hardware processor cause the hardware processor to: configure a preset affinityfactor of each virtual machine; monitor load information of each of physical hosts and virtual machines operating on the physical hosts; calculate a load index of each of the physical hosts and the virtual machines according to the monitored loadinformation; obtain the calculated load index of each physical host, and determine a source physical host on which any virtual machine needs to be migrated so as to reduce the load index of the source physical host; based on determination of the sourcephysical host, obtain the calculated load index of each of virtual machines currently operating on the source physical host, and determine a target virtual machine to be migrated according to a preset affinity factor of each configured virtual machineand respective load index, wherein the preset affinity factor of a virtual machine indicates a degree of dependency of the virtual machine on a physical host in which the virtual machine resides; based on determination of the source physical host,obtain the calculated load index of each of the physical hosts, and determine a destination physical host into which the target virtual machine is to be migrated; and migrate the target virtual machine into the destination physical host. 9. The apparatus according to claim 8, further comprising machine readable instructions that when executed by the hardware processor further cause the hardware processor to: weight the load index of each virtual machine according to therespective preset affinity factor of each virtual machine, and use the virtual machine having a largest weighted load index value as the target virtual machine to be migrated. 10. The apparatus according to claim 8, further comprising machine readable instructions that when executed by the hardware processor further cause the hardware processor to: use a python script to remotely execute a relevant statisticalcommand through a security shell (ssh) so as to obtain the load information of each physical host in monitoring each physical host; and in monitoring each of the virtual machines operating on the physical hosts, use a python script to remotely execute arelevant command through ssh to obtain the load information of the virtual machine from a corresponding process of the physical host where the virtual machine resides, wherein the load information includes central processing unit (CPU) usage, memoryusage and input/output (IO) throughput, and the relevant statistical command is determined according to running processes of the physical hosts. 11. The apparatus according to claim 10, further comprising machine readable instructions that when executed by the hardware processor further cause the hardware processor to: determine an (IO) throughput factor according to the IO throughput,and weight the CPU usage, the memory usage and the IO throughput factor to calculate the load index. 12. The apparatus according to claim 11, further comprising machine readable instructions that when executed by the hardware processor further cause the hardware processor to: select a maximum IO throughput from IO throughputs of all of themonitored physical hosts, and calculate the IO throughput factor of each physical host as a ratio of the IO throughput of the physical host to the maximum IO throughput; and select a maximum IO throughput from IO throughputs of each of the virtualmachines on a monitored physical host, and calculate the IO throughput factor of each virtual machine on the physical host as a ratio of the IO throughput of the virtual machine to the maximum IO throughput selected from IO throughputs of each of thevirtual machines on the monitored physical host. 13. The apparatus according to claim 8, further comprising machine readable instructions that when executed by the hardware processor further cause the hardware processor to: when adding a new virtual machine, obtain the calculated load indexof each physical host select a physical host with a smallest latest load index, and add the new virtual machine onto the physical host. 14. A method for balancing virtual machine loads comprising: monitoring load information for physical hosts and virtual machines operating on the physical hosts; calculating a load index for each physical host of the physical hosts and eachvirtual machine of the virtual machines based on the load information; choosing a virtual machine to be migrated, based on the load indexes of the virtual machines and an affinity factor indicating a degree of dependency of the virtual machine on thephysical host on which it resides; determining a physical host as a destination physical host to migrate the virtual machine to, wherein the destination physical host is determined by at least one of selecting a physical host with a smallest load indexas the destination physical host, selecting a physical host with a load index smaller than a preset threshold as the destination physical host, and selecting a physical host whose load index is smallest and smaller than the preset threshold as thedestination physical host; and migrating the chosen virtual machine to the destination physical host. 15. The method according to claim 14, wherein determining the virtual machine to be migrated comprises: weighting the load index of each of the virtual machines according to a respective preset affinity factor of each of the virtual machines; and selecting a virtual machine having a largest weighted load index value as the virtual machine to be migrated. Description The present application is a 371 application of International Application No.PCT/CN2012/085028 filed on Nov. 22, 2012 and entitled ""Balancing Virtual Machine Load,"" which claims the benefit of Chinese Patent Application No. 201110373058.7 filed on Nov. 22, 2011.BACKGROUND With the development of various technologies of computer and network, various computation resources, memory resources, data resources, software resources and service resources are aggregated in the network. By using virtual machine technology,these dispersed resources can be integrated more effectively so as to realize sharing and effective utilization of resources and to reduce energy consumption. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings illustrate various examples of various aspects of the present disclosure. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent oneexample of the boundaries. It will be appreciated that in some examples one element may be designed as multiple elements or that multiple elements may be designed as one element. In some examples, an element shown as an internal component of anotherelement may be implemented as an external component and vice versa. FIG. 1 is a schematic flow chart of a method of realizing load balance of a virtual machine according to an example of the present disclosure; and FIG. 2 is a schematic diagram of the structure of the apparatus for balancing virtual machine loads according to an example of the present disclosure.DETAILED DESCRIPTION As used herein, the term ""includes"" means includes but not limited to, the term ""including"" means including but not limited to. The term ""based on"" means based at least in part on. In addition, the terms ""a"" and ""an"" are intended to denote atleast one of a particular element. In the following, certain examples of the present disclosure will be described in detail with reference to the drawings. With the reference to FIG. 1, FIG. 1 is a schematic flow chart of a method of realizing load balance of a virtual machine according to an example of the present disclosure. At block 101, a virtual machine management platform periodically monitors the load information of each of physical hosts and virtual machines operating thereon, and calculates load index of each of physical hosts and virtual machinesrespectively according to said load information. The virtual machine management platform operates on a management computer which is communicably connected to each physical host through a network, such as wired network, wireless network, or the like. One or more virtual machines can operate on a physical host. The virtual machine management platform manages all physical hosts in a cluster, including adding a physical host, deleting a physical host, and managing the life-cycle of all virtual machinesby adding, deleting and suspending a virtual machine, etc. through the libvirt. In an example, the load information includes but not limited to CPU (Central Processing Unit) usage, memory usage and IO (Input/Output) throughput of a physical host and avirtual machine. A load index of a physical host or a virtual machine is a value calculated based on the load information, and indicates a degree of total workloads of the physical host or the virtual machine. It is understood that although in this embodiment and other embodiments of the description monitoring is performed periodically, it can be performed in other ways, for example, monitoring continuously. An illustrative approach of calculating the load indexes of each of physical hosts and virtual machines respectively according to the load information is implemented by: determining the IO throughput factor of a physical host/virtual machineaccording to respective IO throughput, and calculating the load index of the physical host/virtual machine by weighting load factors such as CPU usage, memory usage and IO throughput factor of the physical host/virtual machine. An illustrative approach of determining the IO throughput factor according to the IO throughput is implemented by: selecting a maximum IO throughput from the monitored IO throughputs of all of the physical hosts managed by the virtual machinemanagement platform, and calculating the IO throughput factor of each physical host as a ratio of its own IO throughput to the maximum IO throughput; selecting a maximum IO throughput from the monitored IO throughputs of all of the virtual machines on aphysical host, and calculating the IO throughput factor of each virtual machine on said physical host as a ratio of its own IO throughput to the maximum IO throughput selected from the monitored IO throughputs of all of the virtual machines on saidphysical host. The larger the IO throughput factor of a virtual machine, the less should the virtual machine be migrated, because services may be affected during the migration. In the above illustrative approach of calculating, the IO throughput factor of each of virtual machines on a physical host is respectively carried out with respect to that physical host. That is, said maximum IO throughput used in calculatingthe IO throughput factor of each of virtual machines on a physical host is not a maximum IO throughput out of IO throughputs of all virtual machines managed by the virtual machine management platform, instead, it is the maximum IO throughput out of IOthroughputs of all of the virtual machines on that physical host. In an example, block 101 is carried out periodically. It is not necessary to carry out block 101 prior to block 102. At block 102, the virtual machine management platform obtains a preset number of load indexes of a physical host which are monitored at recent continuous times, and if these load indexes of said physical host are all greater than a first presetthreshold (which means any virtual machine operating on this physical host should be migrated so as to lower the load of this physical host), the virtual machine management platform obtains the latest load index of each of the virtual machines currentlyoperating on said physical host, and determines a target virtual machine to be migrated according to preset affinity factors of individual virtual machines and their latest load indexes. In an example, for each of physical hosts, the virtual machinemanagement platform determines whether any virtual machine operating on this physical host should be migrated so as to lower the load of this physical host, as recited in block 102. Once a virtual machine operating on any physical host should bemigrated, the virtual machine management platform obtains the latest load index of each of the virtual machines currently operating on that physical host, and determines the virtual machine to be migrated, as recited in block 102. In this and other embodiments of the description, a preset number of load indexes are mentioned. However, it will be appreciated that a real-time load index is also applicable. In this and other embodiments of the description, a physical hostwhose load index is larger than the first preset threshold is selected as a source physical host on which any virtual machine needs to be migrated so as to reduce its load index. It also will be appreciated that the source physical host can bedetermined in other ways. For example, a physical host with largest load index is selected as the source physical host. The preset affinity factor of a virtual machine used in this block indicates the degree of dependency of the virtual machine on the physical host in which it resides. An illustrative approach of determining the virtual machine to be migratedaccording to the preset affinity factors of individual virtual machines and their latest load indexes is implemented by: weighting the latest load index of each of the virtual machines according to the preset affinity factor thereof, and determining thevirtual machine having the maximum weighted value as the virtual machine to be migrated. From this it can be known that when determining whether or not to migrate a virtual machine according to an example of the present disclosure, not only the loadindex of the virtual machine but also the degree of dependency of the virtual machine on the physical host in which it resides are taken into account. How to set a preset affinity factor and to weight load index according to the preset affinity factorcan be determined by a user in accordance with the specific application condition. At block 103, the virtual machine management platform obtains the latest load index of each of the physical hosts, and determining a physical host whose latest load index is minimum and smaller than a second preset threshold as the destinationphysical host into which the virtual machine is to be migrated. Alternatively, a physical host whose load index is minimum or smaller than the second preset threshold can be selected as the destination physical. The second preset threshold used in block 103 is smaller than the first preset threshold in block 102. At block 104, the virtual machine management platform migrates the virtual machine to be migrated to the destination physical host. Although the flow diagram described above shows a specific order of execution, the order of execution may differ from that which is depicted. For example, the order of execution of two or more blocks may be scrambled relative to the ordershown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. All such variations are within the scope of the present disclosure. The above example is with respect to migrating a virtual machine which is operating on a managed physical host into another managed physical host. In another example of the present disclosure in which a virtual machine is to be newly added, thevirtual machine management platform obtains the latest load index of each physical host, selects the physical host with the minimum latest load index as the destination physical host, and adds the new virtual machine to said destination physical host. In an example of the present disclosure, monitoring is performed to virtual machines being operating on individual physical hosts. In this example, if a virtual machine is not operating, then the process thereof cannot be monitored and the loadinformation thereof cannot be obtained. How to realize balance of loads of virtual machines is described in detail hereinafter by an illustrative example of the present disclosure. A monitoring period for monitoring the physical hosts and virtual machines, i.e. how often an action of load monitoring is executed for the physical hosts and virtual machines, is set through the virtual machine management platform. The periodis 5 minutes by default if not set specifically. An affinity factor is set for each virtual machine to indicate the degree of dependency of the virtual machine on the physical host in which it resides. In an example, the affinity factor can be set tobe a percentage value between 0 and 1. The larger the affinity factor of a virtual machine, the more dependent is the virtual machine on the physical host in which it resides. Usually, migration is not allowed (i.e., the affinity factor is 1), and adefault value of the affinity factor is 0 which means that the virtual machine is not dependent on the physical host. A first preset threshold is set for triggering a load balancing operation, i.e. triggering the dynamic migration of a virtual machine;a second preset threshold is set for determining whether immigration of other virtual machines is allowed for a physical host. The virtual machine management platform periodically monitors each of physical hosts and virtual machines operating on respective physical hosts and obtains the monitoring results thereof respectively, i.e. the load information including but notlimited to CPU usage, memory usage and IO throughput, etc. Monitoring of each of the physical hosts by the virtual machine management platform can be realized by using a python script to remotely execute through ssh (secure shell, ssh) relevant statistical command(s), for example, using commands such ascommand top/iostat on linux. Individual virtual machine operating on a physical host is in substance simulated through a process of the physical host, so in order to monitor a virtual machine, the relevant statistical command(s) can be remotely executed by using a pythonscript through ssh for the correspond process of the physical host in which the virtual machine resides. Taking a case as an example in which an operating process of a physical host is KVM and the CPU usage, memory usage and IO throughput of individual virtual machines operating on the physical host are obtained. Usages of CPU and of memory ofeach of the virtual machines can be obtained by using a python script through top-p pid. The usages of CPU and of memory of a virtual machine obtained herein are not precise values completely conforming to the actual values. Instead, they areequivalent values which represent the actual values in characteristics, that is, said equivalent values increase as the actual values increase and reduce as the actual values decrease. Obtaining the IO throughput is realized by determining virtualmachines in a running state on a physical host through a virsh list, retrieving a list of interfaces names from the xml definition of a determined virtual machine and executing relevant command(s) for each of the interfaces one by one according to theinterface names so as to obtain IO throughout information. The total number of transmitted bytes and the total number of received bytes of the IO throughput of a virtual machine are obtained by respectively summing together the number of transmittedbytes and the number of received bytes at each of these interfaces under the virtual machine. This is an illustrative example, and it is not intended that the present disclosure is limited to this example. In an example, the virtual machine management platform can record each monitoring result and calculate load indexes of physical hosts and virtual machines based on the recorded monitoring results when it is required to determine whether anyvirtual machine needs to be migrated. In another example, the virtual machine management platform may calculate load indexes once a monitoring result is obtained, and record the calculated load indexes in a time order. In this case, the monitoringresults may or may not be recorded. The monitoring results can be stored in a database or a document, or stored in the form of a linked list in a memory. Hereinafter, an example of calculating load index of a physical host i for a monitoring result is described in detail. The monitoring result is obtained and IO throughput factor of the physical host is calculated as described in the above and in the following. The maximum value ioMax is found from IO throughputs of all physical hosts in the monitoring result. Then the IO throughput percentage value (i.e. IO throughput factor) of the physical host which has the maximum ioMax is 1, and IO throughput percentage value (i.e. IO throughput factor) of each of other physical hosts is a ratio of its own IO throughputio to the maximum value ioMax, i.e., io/ioMax. The monitoring result H.sub.i for the physical host i including CPU usage, memory usage, IO throughput and the like of the physical host i is obtained, and the load index of the physical host i is calculated according to the preset weight foreach of the load factors including CPU usage and memory usage obtained from H.sub.i and IO throughput factor calculated as described in the above, etc. Assumed that only the three load factors, CPU usage (A), memory usage (B) and IO throughput factor (C) are considered in determining load index, and the preset weighted values are X, Y and Z for A, B and C, respectively, wherein (X+Y+Z)=1. Theload index L.sub.i of the physical host i is calculated as L.sub.i=A.sub.i*X+B.sub.i*Y+C.sub.i*Z. Assumed that the number of physical hosts in the cluster is hMax, then the value of i is within [0, hMax-1]. In the case where monitoring result is recorded and load index is calculated as needed, a preset number of times N needs to be introduced, then the load index L.sub.in of the physical host i for the (n+1)th monitoring result counted from thelatest result is L.sub.in=A.sub.in*X+B.sub.in*Y+C.sub.in*Z, wherein the value of n is within [0, N-1] and for the latest monitoring data it is 0. In an example, the virtual machine management platform obtains 5 load indexes of each of the physical hosts for corresponding 5 monitoring results monitored continuously. If such 5 load indexes of any physical host all exceed the first presetthreshold, then load indexes of the virtual machines on said physical host are calculated. The way of calculating load index of a virtual machine is similar to that of obtaining load index of a physical host described in the above. The difference incalculating load index between a physical host and a virtual machine at least lies in the way of calculating IO throughput factor, as described in the description of block 102 in FIG. 1. In other examples, more or less than 5 load indexes of each of thephysical hosts are obtained. The virtual machine management platform weights the obtained load indexes of respective virtual machines according to respective preset affinity factors. In an example, the weighting to the load index is implemented by an expression(1-affinity.sub.j)*L.sub.j, wherein the value of j is within [0, VMax-1], VMax represents the number of virtual machines on said physical host. The value of (1-affinity.sub.j) is obtained by subtracting the preset affinity factor affinity.sub.j of avirtual machine j from 1, and serves as a weight value for the load index L.sub.j of the virtual machine j. The virtual machine having the maximum weighted value is determined as a virtual machine to be migrated. As described in the above, the affinityfactor of a virtual machines is set to be a percentage value between [0, 1], wherein 0 represents no dependency, 1 represents great dependency and migration is not suggested. The weight value (1-affinity) means that the larger the affinity factor of avirtual machine, the less willing to be migrated is the virtual machine. The virtual machine management platform further obtains the latest load index of each of the physical hosts in such a way as stated in the above and selects a physical host having the smallest latest load index. If the smallest latest loadindex is smaller than the second preset threshold which means a new virtual machine can be added to the physical host, the physical host is used as a destination physical host for a virtual machine to be migrated. Otherwise, no physical host can acceptthe immigration of the virtual machine to be migrated. In an example, the virtual machine management platform migrates the virtual machine to be migrated to the destination physical host by using virsh tools of libvirt. In another example, the virtual machine management platform also feeds theresult of migration back to the trigger. In an example, no matter a virtual machine to be migrated can be migrated or not finally, the virtual machine management platform records the aforesaid operations in the form of logs for convenience of the administrator. In another example of the present disclosure, when it is determined that there is a physical host whose load is too large and a virtual machine thereof needs to be migrated, firstly it is determined whether or not a relatively idle physical hostexists, if not, the virtual machine to be migrated on the overloaded physical host will be not determined any more. In actual application, a relatively idle physical host for migration usually exists; otherwise, a new physical host will be added intothe system. Based on the same inventive concept as stated above, an apparatus for balancing virtual machine loads is also proposed. Refer to FIG. 2, which is an illustrative diagram of the structure of the apparatus for balancing virtual machine loadsaccording to an example of the present disclosure. In this example, the apparatus comprises: a configuring unit 201, a monitoring unit 202, a calculating unit 203, a first obtaining and determining unit 204, a second obtaining and determining unit 205,a third obtaining and determining unit 206, and a migrating unit 207. Said configuring unit 201 is used to configure the monitoring period, the preset number, the preset affinity factor of each virtual machine, the first preset threshold, and the second preset threshold, wherein said second preset threshold issmaller than the first preset threshold as described in the above. Said monitoring unit 202 is used to monitor the load information of each of physical hosts and virtual machines operating thereon according to the monitoring period configured by the configuring unit 201. Said calculating unit 203 is used to calculate the load indexes of each of physical hosts and virtual machines according to the load information monitored by the monitoring unit 202, for example in a way as described in the above. Said first obtaining and determining unit 204 is used to obtain a preset number, configured by the configuring unit 201, of load indexes of any physical host which is monitored at recent continuous times and calculated by the calculating unit203, and determine that these load indexes of said physical host are all greater than the first preset threshold configured by the configuring unit 201. Said second obtaining and determining unit 205 is used to, when the first obtaining unit 204 determines that those load indexes of any physical host are all greater than the first preset threshold, obtain the latest load index of each of thevirtual machines currently operating on that physical host calculated by the calculating unit 203, and determine the virtual machine to be migrated according to the preset affinity factor of each virtual machine configured by the configuring unit 201 andrespective latest load index thereof, wherein said preset affinity factor indicates the degree of dependency of the virtual machine on the physical host in which it resides. Said third obtaining and determining unit 206 is used to, when the first obtaining unit 204 determines that those load indexes of any physical host are all greater than the first preset threshold, obtain the latest load index of each of thephysical hosts calculated by the calculating unit 203, and determine the physical host whose latest load index is the smallest and is smaller than the second preset threshold configured by the configuring unit 201 as the destination physical host of thevirtual machine to be migrated. Said migrating unit 207 is used to migrate the virtual machine to be migrated determined by the second obtaining and determining unit 205 to the destination physical host determined by the third obtaining and determining unit 206. In an example, said second obtaining and determining unit 205 is used to weight the latest load index of each of virtual machines according to respective preset affinity factor of each virtual machine, and use the virtual machine having thelargest weighted value as the virtual machine to be migrated. In an example, said monitoring unit 202 is used to: use the python script to remotely execute relevant statistical command(s) through ssh so as to obtain the load information of each physical host in periodically monitoring each physical host;and in periodically monitoring each of the virtual machines operating on the physical hosts, use the python script to remotely execute relevant command(s) through ssh to obtain the load information of a virtual machine from the corresponding process ofthe physical host where said virtual machine resides, wherein, said load information include but not limited to CPU usage, memory usage and IO throughput, and said relevant statistical command(s) are determined based on the running process of thephysical host. In an example, said calculating unit 203 is used to determine the IO throughput factor according to the IO throughput, and weight CPU usage, memory usage and the IO throughput factor to calculate the load index. In an example, said calculating unit 203 is used to: select a maximum IO throughput from the IO throughputs of all of the physical hosts monitored by the monitoring unit 202, and then the IO throughput factor of each physical host is a ratio ofits own IO throughput to the maximum IO throughput; and select a maximum IO throughput from the IO throughputs of all of the virtual machines on a physical host monitored by the monitoring unit 202, and the IO throughput factor of each virtual machine onsaid physical host is a ratio of its own IO throughput to the maximum IO throughput selected from the IO throughputs of all of the virtual machines on said physical host. In an example, said third obtaining and determining unit 206 is further used to, when adding a new virtual machine, obtain the latest load index of each physical host calculated by the calculating unit 203, and select the physical host with thesmallest latest load index, and add the new virtual machine onto said physical host. The aforesaid units discussed in the above can be integrated or arranged separately. These units can be combined into one unit or subdivided into a plurality of sub-units. The above examples can be implemented by hardware, software or firmware or a combination thereof. For example the various methods, processes and functional modules described herein may be implemented by a processor (the term processor is to beinterpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate array etc.). The processes, methods and functional modules may all be performed by a single processor or split between several processors; reference in thisdisclosure or the claims to a `processor` should thus be interpreted to mean `one or more processors`. The processes, methods and functional modules be implemented as machine readable instructions executable by one or more processors, hardware logiccircuitry of the one or more processors or a combination thereof. Further the teachings herein may be implemented in the form of a software product. The computer software product is stored in a storage medium and comprises a plurality of instructionsfor making a computer device (which can be a personal computer, a server or a network device such as a router, switch, access point etc.) implement the method recited in the examples of the present disclosure. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the processes or blocks of any method so disclosed, may be combined in any combination, except combinations where atleast some of such features and/or processes or blocks are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unlessexpressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. Examples of the present disclosure determine a dynamic migration action of a virtual machine by comprehensively considering load information such as CPU usage, memory usage and IO throughput of physical hosts and virtual machines, whereby loadbalancing of virtual machines distribution is realized, and smooth migration of a virtual machine is effectively enhanced so that influence on the virtual machine caused by migration of the virtual machine with high memory usage and IO throughput isavoided. Through examples of the present disclosure, it is not required to mount a proxy in advance on a physical host or a virtual machine, whereby complexity and cost are reduced. In some example, not only CPU load of a physical host but also load ofa virtual machine on said physical host are taken into account. In an example, an affinity factor of a virtual machine that represents the degree of dependency of the virtual machine on the physical host in which it resides is configured, and dynamicmigration is less suggested with the increase of the affinity factor. In the above description, the drawings are merely schematic drawings of an example, and the modules or flows in the drawings are not necessary essential for carrying out the disclosure. The above sequential numbers mentioned are only forfacilitating description, but they are not used to represent which example is more advantage. The above description includes examples. Any modification, equivalent substitution and improvement made that are according to the spirit and principle of theexamples shall be included in the protection scope."
19|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=43&p=1&f=G&l=50&d=PTXT&S1=(python.CLTX.+or+python.DCTX.)&OS=ACLM/python&RS=ACLM/python|Tapping head, tapping device and method for use of a tapping device|A tapping head, provided with a connecting head near an end of a housing, wherein the tapping head is provided with at least one of a beverage channel which extends from a beverage line connection into the connecting head and a gas channel which extends from a gas line connection, wherein the tapping head is provided with at least one cooling chamber with an entrance and an exit, separate from the beverage channel and/or the gas channel, which cooling chamber is in thermal contact with the housing.|