- From: Jens de Smit <jens.desmit@surfnet.nl>
- Date: Tue, 03 Aug 2010 16:41:22 +0200
- To: Thomas Wrobel <darkflame@gmail.com>
- CC: roBman@mob-labs.com, cperey@perey.com, public-poiwg@w3.org
On 31/07/2010 00:36, Thomas Wrobel wrote: > On 30 July 2010 09:24, Rob Manson <roBman@mob-labs.com> wrote: >> Hi, >> >>>>> should return (send via an IP network if it is in the cloud, retrieve if >>>>> it is stored locally) to the user's device that digital data with which >>>>> the trigger was previously associated (by a publisher, in the broadest >>>>> sense of the word). >>>> >>>> Also "or access as a stream from a local sensor (e.g. camera or even a >>>> VOIP connection)." >>>> >>> >>> here, do you propose that the data returned or "played" can, optionally, >>> be a real time dynamic data stream? >> >> Yes. > > A +1 to having the mapping of a trigger to dynamicly updated data. > > Wouldn't this, effectively, be mapping to a URL or IP though? > > So that athlete is broadcasting his pulse to a IP/port, and the AR > software used by a viewer has associated his position (taking from a > logo on his tshirt) to a read-out of that data? > > So a general > <trigger> <IP/Port data source> should cover a lot of potential > streams. Having a MIME type specified perhaps so the client knows if > it can interpret the data being broadcast? Hi, Mapping specifically to IP (v4? v6?) sounds a bit... limited. Data could be coming from any byte stream or packet stream. IPv4/v6 is a likely candidate in an internet situation, but we shouldn't exclude local files or things like Bluetooth in Personal Area Networks. Regards, Jens
Received on Tuesday, 3 August 2010 14:41:53 UTC