Abstract: Caching of an immutable buffer that has its data and address prevented from changing during the lifetime of the immutable buffer. A first computing entity maintains a cache of the immutable buffer and has a strong reference to the immutable buffer. So long as any entity has a strong reference to the immutable buffer, the immutable buffer is guaranteed to continue to exist for the duration of the strong reference. A second computing entity communicates with the first computing entity to obtain a strong reference to the immutable buffer and thereafter read data from the immutable buffer. Upon reading the data from the cache, the second computing entity demotes the strong reference to a weak reference to the immutable buffer. A weak reference to the immutable buffer does not guarantee that the immutable buffer will continue to exist for the duration of the weak reference.

Abstract: The environment and use of an immutable buffer. A computing entity acquires data or generates data and populates the data into the buffer, after which the buffer is classified as immutable. The classification protects the data populated within the immutable buffer from changing during the lifetime of the immutable buffer, and also protects the immutable buffer from having its physical address changed during the lifetime of the immutable buffer. As different computing entities consume data from the immutable buffer, they do so through views provided by a view providing entity. The immutable buffer architecture may also be used for streaming data in which each component of the streaming data uses an immutable buffer. Accordingly, different computing entities may view the immutable data differently without having to actually copy the data.

Abstract: Caching of an immutable buffer that has its data and address prevented from changing during the lifetime of the immutable buffer. A first computing entity maintains a cache of the immutable buffer and has a strong reference to the immutable buffer. So long as any entity has a strong reference to the immutable buffer, the immutable buffer is guaranteed to continue to exist for the duration of the strong reference. A second computing entity communicates with the first computing entity to obtain a strong reference to the immutable buffer and thereafter read data from the immutable buffer. Upon reading the data from the cache, the second computing entity demotes the strong reference to a weak reference to the immutable buffer. A weak reference to the immutable buffer does not guarantee that the immutable buffer will continue to exist for the duration of the weak reference.

Abstract: The environment and use of an immutable buffer. A computing entity acquires data or generates data and populates the data into the buffer, after which the buffer is classified as immutable. The classification protects the data populated within the immutable buffer from changing during the lifetime of the immutable buffer, and also protects the immutable buffer from having its physical address changed during the lifetime of the immutable buffer. As different computing entities consume data from the immutable buffer, they do so through views provided by a view providing entity. The immutable buffer architecture may also be used for streaming data in which each component of the streaming data uses an immutable buffer. Accordingly, different computing entities may view the immutable data differently without having to actually copy the data.

Abstract: An index update component updates an index of a database in response to a query to the database referencing the index. An index control record tracks the last time the index was referenced and state of the index compared to the state of the database. An index deletion component deletes indexes in the database that have not been referenced for a period of time.

Abstract: A request logging component formulates an index that could have been utilized by a query to a database, if the index had existed. The request logging component stores the formulated query as an unsatisfied request. The index creation component creates the index of the database from the unsatisfied request.

Abstract: A method and system for fragment-based serialization places one or more object members in fragments. Fragments may comprise a header and a payload. A header can provide useful information about the fragment, such as an indication of fragment type and an indication of fragment length. A payload may comprise one or more members of an object. Primitive members may be stored in a Binary Fragment with a record format payload. LOB and FS members may be stored in fragments that have a Value Type field for setting forth additional properties of the fragment. Collections may be stored in a series of fragments, a first fragment to indicate a start of a collection, one or more second fragments to serialize collection elements, and a Terminator Fragment to indicate the end of a collection. Fragment-serialized objects minimize storage overhead while providing fast instantiation and low-cost location and updating.

Abstract: Techniques and tools for implementing a source code annotation language are described. In one aspect, keywords are added to a function interface to define a contract for the function independent of function call context. In another aspect, annotations are inserted at global variables, formal parameters, return values, or user-defined types. The annotations include, for example, properties and qualifiers. A property can indicate, for example, a characteristic of a buffer. In another aspect, an annotation indicates that a value has usability properties sufficient to allow a function to rely on the value, where the usability properties depend on value type.

Abstract: A technique for representing the structure of hierarchically-organized data in a non-hierarchical data structure, such as a relation. The hierarchically-organized data is represented as a tree, and each node in the tree is assigned a position identifier that represents both the depth level of the node within the hierarchy, and its ancestor/descendant relationship to other nodes. The data represented by each node, as well as its position identifier, is stored in a row of a relational database, thereby capturing the hierarchical structure of the data in such relational database. A technique is provided for the compressed storage of position identifiers in a format that allows an efficient bytewise comparison of position identifiers to determine relative order and ancestry.

Abstract: Various embodiments of the present invention are directed to a data store comprising Items, Elements, and Relationships. An Item is a unit of data storable in a data store and further comprises said Element and said Relationship. An Element is an instance of a type comprising one or more fields. A Relationship is a link between at least two Items. The data store further comprising a Core Schema to define a set of Core Items by which a hardware/software interface system understands and directly processes said set of Core Items in a predetermined and predictable way. The Core Items are derived (directly or indirectly) from a common single Base Item which, in turn, is a foundational Item in a Base Schema.

Abstract: A technique for representing the structure of hierarchically-organized data in a non-hierarchical data structure, such as a relation. The hierarchically-organized data is represented as a tree, and each node in the tree is assigned a position identifier that represents both the depth level of the node within the hierarchy, and its ancestor/descendant relationship to other nodes. The data represented by each node, as well as its position identifier, is stored in a row of a relational database, thereby capturing the hierarchical structure of the data in such relational database. A technique is provided for the compressed storage of position identifiers in a format that allows an efficient bytewise comparison of position identifiers to determine relative order and ancestry.

Abstract: A request logging component formulates an index that could have been utilized by a query to a database, if the index had existed. The request logging component stores the formulated query as an unsatisfied request. The index creation component creates the index of the database from the unsatisfied request.

Abstract: An index update component updates an index of a database in response to a query to the database referencing the index. An index control record tracks the last time the index was referenced and state of the index compared to the state of the database. An index deletion component deletes indexes in the database that have not been referenced for a period of time.

Abstract: A technique for representing the structure of hierarchically-organized data in a non-hierarchical data structure, such as a relation. The hierarchically-organized data is represented as a tree, and each node in the tree is assigned a position identifier that represents both the depth level of the node within the hierarchy, and its ancestor/descendant relationship to other nodes. The data represented by each node, as well as its position identifier, is stored in a row of a relational database, thereby capturing the hierarchical structure of the data in such relational database. A technique is provided for the compressed storage of position identifiers in a format that allows an efficient bytewise comparison of position identifiers to determine relative order and ancestry.

Abstract: A Web crawler creates an index of documents in a document store on a computer network. In an initial crawl, the crawler creates a first full index for the document store. The first full crawl is based on a set of predefined “seed” URLs and crawl restrictions, and involves recursively retrieving each folder/document directly or indirectly linked to the seed URLs. In the process of creating the first full index, the crawler creates a History Table containing a list of URLs for each folder and document found in the first full crawl. The History Table also includes a local commit time (LCT) for each document and a deleted documents count (DDC) and LCT or maximum LCT (MLCT) for each folder (this assumes that the store supports a folder hierarchy and the MLCT, LCT and DDC properties). Thereafter, in an incremental crawl, the crawler determines, for each folder, (1) whether the DDC for that folder has changed and (2) whether the MLCT is more recent than the corresponding value in the History Table.

Abstract: A technique for representing the structure of hierarchically-organized data in a non-hierarchical data structure, such as a relation. The hierarchically-organized data is represented as a tree, and each node in the tree is assigned a position identifier that represents both the depth level of the node within the hierarchy, and its ancestor/descendant relationship to other nodes. The data represented by each node, as well as its position identifier, is stored in a row of a relational database, thereby capturing the hierarchical structure of the data in such relational database. A technique is provided for the compressed storage of position identifiers in a format that allows an efficient bytewise comparison of position identifiers to determine relative order and ancestry.

Abstract: A Web crawler application takes advantage of a document store's ability to provide a content identifier (CID) having a value that is a unique function of the physical storage location of a data object or document, such as a Web page. In operation, the crawler first tries to fetch the CID for a document. If the CID attribute is not supported by the document store, the crawler fetches the document, filters it to obtain a hash function, and commits the document to an index if the hash function is not present in a history table. If the CID is available from the document store, the CID is fetched from the document store. The crawler then determines whether the CID is present in the history table, which indicates whether an identical copy of the document in question has already been indexed under a different URL.

Abstract: A computer system data container such as a directory or data folder includes various items (e.g., e-mail messages) having item level security controls. In this invention, the computer system ignores files for which the viewer has no viewing rights when summary data about the data container is displayed on the viewer's monitor. For each item level security setting, a running total is kept of an aggregate property (e.g., count of, size of) of all the items in the directory or folder of that security setting. Changes to the running total occur as items are added or deleted, or edited if the aggregate property is the size of all items of that security setting. Regardless of what the aggregated data is, the computer system adds only the running totals for which the user has viewing rights when computing summary data. Thus, the user cannot infer anything about non-viewable items from the summary data.

Abstract: Systems and methods for enforcing access control on secured documents that are stored outside of the direct control of the original application that would normally store and govern access to the documents. Access security can be enforced at a search engine associated with an indexing system that compiles references to documents at any number of network locations. The search engine discloses to the requesting user only those documents that the user is authorized to read. If a document is identified for potential disclosure to a user, and the document's source location has an access control system that is not directly interoperable with a native access control system of the search engine, a security provider at the search engine enforces access control. The security provider, in cooperation with the source location of the document, converts the user context that identifies the requesting user to a format that can be used by the security provider.