Good comments ... Pragmatically speaking, we have a system in production that uses both paradigms. This event pattern you describe here is used for routine data reporting and notification of attention-worthy things (alerts). If someone wants to do realtime monitoring, the alert notification includes the URI of a raw datastream for further detailed examination of the situation (private-raw-scheme://detector-ip:port/feed).
- Rob ----- Original Message ----- From: "John D. Mitchell" <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, October 12, 2007 12:52:27 PM (GMT-0500) America/New_York Subject: Re: Newbie question: How to stream data between RESTlets On 10/12/07, Erik Vullings <[EMAIL PROTECTED]> wrote: [...] > I have two RESTlets, one acting as a sensor, the other as a detector. The > sensor serves data that is consumed by the detector. Since the sensor > RESTlet continuously generates data, I want to stream this data to the > detector(s) RESTlet. What's the best way to do this? First off, Rob made a number of good points that should be consider so I'll approach this from a completely different angle for a different perspective... :-) You might find it much easier to turn your relationship around... I.e., rather than having the sensor try to stream the data to the detector over long periods, just have the sensor send "events" to the detector. Depending on the period, data volume, etc. you can have the sensor bundle them into groups and send entire bundles per round. If you configure your client and server to both allow pipelining then the setup and teardown costs of the underlying channel is amortized over a number of individual rounds. > And what kind of > representation should the sensor generate if we are dealing with simple data > ( e.g. numbers). If I get a good solution, I promise to put it on the new > Wiki. Do you need any structured information about the data elements or is it a uniform stream of numbers that are all the same? Is there optional information or is it always uniform? If it's always uniform then I'd do the old Unix stream game and just return the numbers 1 per line or one set per line. If ordering across bundles matter then add a full timestamp and a sensor specific full ID and perhaps a nonce as the first two lines of each bundle. Hope this helps, John
