On 01/09/2012 08:46 PM, Dave Cridland wrote:
> On Mon Jan 9 13:28:48 2012, Sergey Dobrov wrote:
>> As I can understand, you just have a service which tracks other users
>> locations. For such reason, current PEP is really suitable. But if you
>> will try to track one's location by many users you will have a problem
>> because you will need to do many "from" subscriptions ('cause this user
>> doesn't want to be abused of locations of all these users who wants to
>> track his location), the current PEP will not work for you anymore.
>
> I think this is a terrible example.
Not so vital but possible in some specific applications. Even if we have
a microblogging application we can track geolocation too :)
>
> Your microblogging example is much better, because it seems reasonable
> that one might want to follow a microblog of, say, some commercial
> company without letting them have the possibility to track their
> subscriber's presence.
>
> But there's more than that, too - you'd want to get the microblog in
> total, rather than having to be online to keep track of it - that is,
> you don't want to miss any posts. So when your special microblog client
> comes online, you want to pick up everything that happened while you
> were offline - a specialist offline message queue. It's this that I
> described in my other email as a PEP Inbox - a poor term, I know.
Yes, that is the problem too. For now I just query 10 last messages for
each contact in my roster and I deferred the decision of this question
for some time such way. But I already decided to make a new feature for
pubsub nodes which will implement some kind of journal where will be
written any node action and node will have a revision which will be
transmitted in each event. So, a client will be able to know if it has
the newest representation of node in it's cache and if it is not then it
will be able to query journal events since the moment it have no
updates, remove items that was retracted and query new items it was not
received. This decision will allow to track not only new messages but
also retracts/configuration changes/any other events.
>
> But it has other applications, as well - push notifications from other
> sources can be broadcast out to all users without regard for their
> online status, knowing that the user will get the info.
>
> This is what I need - far more than concerns over whether the event
> source can track my presence or not (in fact, I even want them to, in a
> lot of cases, at least some of the time).
>
> My problem with your proposed solution is that:
>
> a) It involves changing PEP very heavily, and in a way that breaks many
> of its existing deployments.
>
> b) It doesn't solve the problems anyway.
>
> I do *not*, however, think that problems don't exist, or that your
> problems aren't valid. They are - but I think we can solve them in a
> different, and better, way.
I hope so. But I have no other good idea. Maybe I will use patched
ejabberd module until we have no standardized solution.
>
> (BTW, are you coming to the Summit? We could have a chat about this.)
I'd be pretty happy to take a participation in it but I am located far
far away in West Siberia so I will have no possibility to do that (I
never was in any Europa country and even don't know which requirements I
must met, etc). Also, my speech English is bad.
>
> Dave.
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
