Hobby OS projects (by alaric)
One of the reasons I'm interested in a database of logical statements being the native form for an entity's state is that they form a big part of how information is obtained from entities. The MERCURY protocol provides a much higher level feature set than TDP or UDP - or even HTTP and BEEP. It indirectly supports clustering, by identifying the target entity of a request by a cluster ID and an entity number within that cluster, and using a mechanism I won't go into here to find a node in that cluster efficiently to handle the request, and allowing that node to 'redirect' to another node in the cluster if it's busy or is administratively prohibited from responding to the request itself (for example, if it is not cleared to access the state of the entity, according to the mandatory access control rules in force). However, it has special support for idempotent operations that do not change the persistent state of the target entity - roughly equivalent to HTTP GETs.
In particular, it defines them in terms of a database of logical assertions stored in the entity, which can be queried via the MERCURY protocol. This means that an entity with a complex internal data model does not need to define a sea of "get methods" - getAllCustomers returning a list, getCustomer(customerID), getCustomerDetail(customerID) returning the bulky extra data (such as photographs) not normally returned by the other two methods since they're rarely needed, etc. Instead, it just defines its data model directly, and lets clients submit structured queries for just the data they want.
The details of this are implemented in a component that sits on top of MERCURY proper, since MERCURY just provides the basic request/response handling; and that component is called CARBON. CARBON provides a protocol implemented on top of MERCURY (although appearing as part of it to the application developer or user) for accessing this data with queries. Most of the complexity is optimisations; for a start, much of this data can be cached locally or on intermediate routers, so the server entity needs to provide cache TTLs for its information. Secondly, entities with less than a certain amount of purely static data may just reply to all requests with all of that data - sort of like RDF over HTTP - since it's not worth working out and sending a subset, and risking the client then having to ask again for some more information; much like DNS servers, the CARBON system on the server node may choose to send more information back than was requested, based on the knowledge that the client is likely to want it anyway.
Finally, entities may not necessarily just have a static database of knowledge. Perhaps they need to run actual code to answer queries, either consulting hardware to obtain current data or gatewaying the request into a different protocol (such as standard Internet protocols). In which case, they just leave a stub statement in their static knowledge base that matches the types of queries needing this treatment, and requests for that information result in the handling of the request by invoking entity code; yet also, if such stub statement handlers do not need access to special resources within the entity (for example, a service that accepts a number and returns it in Roman numerals), then the handler can instead by bundled up in the static knowledge base as an 'applet' that is transparently executed in a sandbox on the client side.
Sun 16th Jul 2006 12:15 am 
Subscribe
By James, Thu 18th Dec 2008 @ 11:13 am
So whens the release? 😛 Wouldn't mind testing this thing with a couple of old forth apps I got kicking around on my drive. -Jim