Node Build and Configuration Notebook - page 22 of 55

First PagePrevious PageNext PageLast PageTable of ContentsSearch

Date and Author(s)

Converging Information Service Abstractions

Another title for this posting could be: 
  Notes and thoughts from 2/1/2002 Information service meeting. 
Information Service scope clarification 
The scope of the Information Service is to provide a common data 
storage and access API for SSS software components. The Information 
Service is not for applications or direct user access. 
Information Service design goals 
We discussed the goal that the Information Service design be simple 
enough to implement without supporting information storage software, 
yet flexible enough that it could be built on top of any such software, 
like: flat files, a relational database, LDAP, or others. 
Space management 
Do we need some space management capability to avoid memory leaks or 
prevent keeping information that we don't wish to retain? A proposal 
was that the information service have some awareness of persistance 
with an external component triggering removal of non-persistant data. 
The other proposal was that if a component cares about persistence, 
it implement watchdog type capabilities to monitor and cleanup 
after itself. The basic distinction being, does this need to be a 
core Information Service feature? 
There were issues regarding the ability of components to overwrite data 
from other components, and the ability of writers to tell the Information 
Service that data couldn't be overwritten.  This lead to discussions on 
how to manage data that couldn't be overwritten.  An easy initial approach 
to this issue is to punt and state that initially we expect all components 
to register unique data keys and not mess with each others data.  In the 
future we could implement some authentication and authorization features 
in the information service. 
Information Service understanding what data it stores 
The proposal was made that the Information Service only be aware of the 
data key, and some protection attributes, and not of the blob of data 
attached to the key.  Is this primarily a usage proposal? That multiple 
values be stored as a single blob leaving the task of decoding the 
contents of the blob to provider and consumers of the data?  This could 
be done even if the Information Service supports multiple data values for 
a key. The question perhaps becomes, do we require this encoding and 
decoding by only allowing one value per key? 
Raw data in the Information Service 
Although it's not clear whether this is necessary we did discuss the 
ability of the information service to store RAW data.  Since our API 
is XML based we discussed that RAW data capabilities would probably 
require the use of non-XML sockets. One possible design approach 
is for the client to send a XML request to the server stating that 
it has raw data it wishes to store, along with key information. 
The server would open a socket and respond saying "send your data to this 
socket". The client would send the data and tell the Information Service 
"done", to which the Information Service would respond "done storing". 
Retrieval could be done as follows: client opens a data socket and XML 
socket and sends to the XML socket a well formed XML request saying 
"send raw data identified by key to my data port". The server would send 
the RAW data to the data port and respond via the XML channel "done". 
Again, we don't have a real application for this yet, 
but we might need it. 
Well, how do we converge these proposals?  Would e-mail discussions be 
appropriate?  Should we consider opening this discussion to a wider 
SSS audience?