2009/7/7 Dirk Meyer <[email protected]> wrote: > What's missing is a way to > use auto-subscribe with [timestamp constraints]
While it makes a great deal of sense to be able to subscribe with a constraint on timestamps, I would encourage you not to try to make this a standard configuration option. For any subscription other than one that gets all items published to a node, you really should be using "content-based" subscription_options. The should be a clear distinction between "topic-based" pubsub and "content-based" pubsub. Also, we can expect that over time there will be many ways that people want to constrain the messages that are delivered to them. Some may want a simple timestamp based constraint. Others will want only messages that contain a particular keyword (like the "track" option in some microblogging systems), others will want more complex boolean search queries. It is best if all of these constraints are handled consistently rather than having some done as attributes on the configuration and others done as explicit fields in the subscription_options form. This may seem like "over kill" for such a simple constraint today. However, a few years from now, it will look like a "clean separation." bob wyman 2009/7/7 Dirk Meyer <[email protected]> > Peter Saint-Andre wrote: > > On 6/3/09 9:43 AM, Dirk Meyer wrote: > >> Brian Cully wrote: > >>> I'm not sure if it's entirely appropriate to shoehorn it into > >>> pubsub, since you can probably take care of this within a given > >>> application, but doing it at the pubsub level would make it easier > >>> for app developers and allow for easier distribution of item > >>> publishes without having to share state outside of XMPP. > >> > >> It works without extra support in pubsub. It would be similar to roster: > >> on every startup my application would contact all pubsub servers it > >> stores stuff on and fetches all items from the persistent storage. My > >> idea would reduce the traffic just like roster versioning does. It is a > >> nice add-on. > > > > What exactly needs to change in the spec to make this happen? > > Bob Wyman gave me the idea to re-use the timestamps discussed on another > thread. The idea is good and solves half my problem. Using the timestamp > I can keep track of changes on the server. What's missing is a way to > use auto-subscribe with that feature. I want to know if the node has new > or deleted items since I was last (auto) subscribed. Instead of sending > the latest item on subscribe, the server sends the last timestamp of a > change on the node (which could be a delete event that can not be > detected by sending the latest item). > > So what I need as spec besides the timestamp discussed in the other > thread are a two new possible values for the configuration option > pubsub#send_last_published_item: timestamp_on_sub and > timestamp_on_sub_and_presence. The behave similar to the values without > the timestamp_ prefix. The difference is that the server does not send > the real last published item and only the timestamp of the last change > instead: > > <message from='pubsub.shakespeare.lit' to='[email protected]' > id='autosub'> > <event xmlns='http://jabber.org/protocol/pubsub#event'> > <items node='princely_musings' timestamp='...'> > </event> > </message> > > Does this make sense? > > > Dirk > > -- > $100 placed at 7 percent interest compounded quarterly for 200 years will > increase to more than $100,000,000 - by which time it will be worth > nothing. > [Robert A. Heinlein > 1907-1988] >
