Re: Pachube and POI

Well, yes, this is exactly what we are doing with arwave, attempting
to solve both the realtime and social (that is, private group<>group)
communication of geolocated data while staying federated. ARwave,
naturally, use's XMPP.

To be honest, I haven't had much time to look at Pachube so I can't
really fairly go into the pro's/con's of each system. My instincts are
that Pachube will be easier to set up, and WFP (wave federation) will
be more flexible in the long run.

And yes, as Jens says the direction things are going is fine - our
system is pretty natural to the data format of POIs or the 3D formats,
as long as data can be freely added and subtracted without needing to
explicitly come from the same source. (so, for example, positioning
one thing relative to another should be possible with some sort of
unique ID/URI rather then having to implicitly inferred ver a xml
style markup).

I'll try to find time to look into Pachube, however, as well as
everyones papers over the next few weeks.


-Thomas
arwave.org

~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 31 January 2011 14:26, Jens de Smit <jens@layar.com> wrote:
> On Thu, Jan 27, 2011 at 8:15 PM, Christine Perey <cperey@perey.com> wrote:
>> Hello,
>>
>> During our meeting January 26 I agreed to do some research on Pachube as a
>> basis for understanding the needs/possible synergies between this platform
>> and the POI WG work.
>>
>> The specific area we would like to better understand is how to manage the
>> frequent requests for information, and frequent updates to information in a
>> database. I thought that the requirements we have for objects which are
>> changing locations over time might have something in common with what
>> Pachube does.
>>
>> I want to introduce those of you who are not familiar with it to the system.
>>
>> From the home page:
>>
> <snip Pachube intro>
>> I suggest that you study:
> <snip links>
>> What are your thoughts?
>
> Hi Christine,
>
> What is impressive about Pachube is that they handle a lot of sensor
> values internally, values coming from a huge amount of data-producing
> sensors to a (potentially) large amount of data-consuming entities.
> However, the Pachube data format is "nothing special" as far as I can
> see. The data delivery method is standard HTTP, with the option of
> getting "push" data when a predefined condition is met, also over
> HTTP.
>
> If we really worry about frequent, _real-time_ updates it is possibly
> better to look at the data transport method than at the data format.
> Cue Thomas Wrobel :P In all seriousness, XMPP or something derived
> from that could be very important for these real-time tracking
> applications. This means that it is important that the data format we
> come up with is capable of adding and subtracting pieces of data into
> an existing set. However, looking at the direction we're headed, I do
> not anticipate problems with that. Still, keeping it in the back of
> our heads sounds like a bright thing to do.
>
> Regards,
>
> Jens
>
>
>

Received on Monday, 31 January 2011 14:38:45 UTC