[infod-wg] FW: A few very rough "level 1" thoughts

Fisher, SM (Steve) S.M.Fisher at rl.ac.uk
Thu Jul 20 10:16:29 CDT 2006


 

-----Original Message-----
From: Fisher, SM (Steve) 
Sent: 20 July 2006 14:32
To: 'Vijay Dialani'; 'Dieter Gawlick'
Subject: A few very rough "level 1" thoughts

This very short note trys to explore the additions necessary to INFOD to
allow an INFOD implementation to also be an R-GMA implementation. Some
of these additions may be general and so be suitable for the "level 1"
spec but others are more likely to be very specific to R-GMA. It
actually seems a bit harder than I had hoped! 


First we need a simple disseminator to emulate an R-GMA producer. This
needs to accept the results of SQL INSERT tatements for which it might
use the existing "consume" interface.  It will need some kind of
resource management as each user publishing via an R-GMA producer has
his own "instance". Each instance needs its own state to identify the
tables it is publishing and the "properties" (storage type, retention
periods and type of supported queries) of that instance. The simple
disseminator of course requires storage and would need to implement the
R-GMA login to push data from the disseminator to the postbox. This
logic shoudl not be too hard with the current registy functionality.

To implement an R-GMA consumer mechanism, we would need something along
the lines of the old postbox mechanism. You weed need to create a
postbox instance (where instance and resource can be seen as roughly
synonymous) with your query and periodically get data from it. Evidently
the postbox also needs storage - and management of that storage. Note
that results of continuous and non-continuous queries are handled the
same way by R-GMA as the tuples are only sent to the user in finite size
chunks - asking for a block of indeterminate size is a good way to crash
a program! The continuos query just never comes to and end.

My next step is to identify what can be general and what is specific to
R-GMA


Considering the use of RSS - this seems to me to be an alternative to
WSN and could supplement the push to a consume interface. This has
noting to do with the above ideas however.

Steve





More information about the infod-wg mailing list