Is there any possibility to add these features to the XEP-60?
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-uns...@jabber.org
_______________________________________________
On 11/22/10 9:11 PM, Sergey Dobrov wrote:
> Why there is no way to retrieve a timestamp where an item was published?
> Why there are no possibility to retrieve an items that newer (or older)
> that specified timestamp?
>
> Is there any possibility to add these features to the XEP-60?
We've had other requests for at least the "retrieve since" feature. The
best way to do that might be to do presence-based notifications and
include the last logout time in initial presence.
Peter
--
Peter Saint-Andre
https://stpeter.im/
I have working prototype of microblogging service using PEP and Pubsub
with code name LiJ. Since my initial message I had some problems and I
wish to solve them but I don't know how I can interact with XSF more
effectively.
Presence based notifications is good idea but it can't be the only way
to solve it. I think that we need a possibility to manually request
items since some time moment. I wish to specify that it's important to
send not only new items notifications but items retract notifications too.
I have some other suggestions to pubsub protocol based on experience of
usage by microblogging system development and if you wish to solve the
problems I will post them here or somewhere you wish.
Thanks.
>
> Peter
>
>
>
>
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-uns...@jabber.org
> _______________________________________________
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
_______________________________________________
JDev mailing list
> Presence based notifications is good idea but it can't be the only
> way
> to solve it. I think that we need a possibility to manually request
> items since some time moment. I wish to specify that it's important
> to
> send not only new items notifications but items retract
> notifications too.
The problem with sending retraction notices is basically that a
retraction is a deletion, and once we're storing these, it means
storing tombstones. I have a general aversion to storing tombstones.
> I have some other suggestions to pubsub protocol based on
> experience of
> usage by microblogging system development and if you wish to solve
> the
> problems I will post them here or somewhere you wish.
Here is OK, but social, pubsub, or standards might be best.
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Thanks
>
>
>> Presence based notifications is good idea but it can't be the only way
>> to solve it. I think that we need a possibility to manually request
>> items since some time moment. I wish to specify that it's important to
>> send not only new items notifications but items retract notifications
>> too.
>
> The problem with sending retraction notices is basically that a
> retraction is a deletion, and once we're storing these, it means storing
> tombstones. I have a general aversion to storing tombstones.
I understand this and agree but otherwise it will be very hard to sync
local copy of node and remote. (For example, in my blog web interface to
it acts as aggregator: it subscribes to all users and put posts to
database to represent them in web. if aggregator is down for any reason
removed posts will be permanently forgot at web). Obviously, service can
just retrive all items IDs for a node and check if all stored IDs still
there but for long threads it may be overhead. Another way is to make
retracted items just empty but this seems to be dirty decision too...
>
>> I have some other suggestions to pubsub protocol based on experience of
>> usage by microblogging system development and if you wish to solve the
>> problems I will post them here or somewhere you wish.
>
> Here is OK, but social, pubsub, or standards might be best.
Ok, thanks
>
> Dave.
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
_______________________________________________
We were confronted with the same problem at buddycloud and putting
timestamps in presence gave us some headaches:
<presence/> is cached on the server side and can be resent to a service
coming online and probing for presence, resulting in potentially
unneccesary history pushes. An entity interested in just history may not
be required to send presence, because that also includes notification
<message/> stanzas. From a bird's eye view requesting history is a
pretty use case for <iq/> RPC semantics.
Also problematic with a one-shot approach: if there had been a network
partition in effect when the user logged out, the missing items won't be
included in history. Another pretty obvious problem with using single
timestamps on a global base is clock skew in the heterogenous XMPP
network.
The approach we agreed upon is based on the knowledge of all user
subscriptions at a user's home pubsub service: it knows about the "last
synchronization time" per service or node, and will recurse the history
request to all remote service with that particular information. The
incentive for that mechanism was saving on round-trips for mobile
clients that are interested in synchronizing with multiple pubsub
services.
Stephan
_______________________________________________
JDev mailing list