On Tue, Nov 24, 2009 at 8:21 PM, Brian Cully <[email protected]> wrote:
> On 19-Nov-2009, at 00:48, Ville Varis wrote: > > All the rest from my post, I still agree with that 'ver' should be able > to placed by publisher and this feature must be optional. Reasoning for > Service to generate 'Ver' exists, and that is good for sure for many cases. > > > > My main point being there exists also reasoning and use cases to allow > publisher to set 'Ver' > > I think what you want in these cases is to have the publisher > include some kind of version (a timestamp, if you wish) in the payload, and > then use a content based service to handle aggregation, de-duping, > filtering, or what have you, based on the version in the payload. I'm loathe > to let the publisher set the version, since it's probably going to no more > correct than the server-generated one and it doesn't seem to solve any > problem that can't already be solved with content based services. > > It appears you want to configure these arbitrary reflectors and > aggregators, and while this may be a worthy goal, at the end of the day I > think you're going to want to use out-of-band channels to handle the myriad > issues that arise with such services, and thus it doesn't need to be encoded > in the specification of generic publish subscribe. > > -bjc I object what you said with all experience from building generic flow-oriented (insert-update-remove flow) publish-subscribe system where this kind of 'ver'sioning is critical concept to identify each published data item by it's subject/node (you may have many flow for same subject/code), by different data (item id) and at the end by time with consistent versioning. And yes, would the XMPP offer transien enough handling to publisher to handle any new subscriptions made, I can build all these algorithms just as I like to, but it costs the de-serialisation of payload for all the data and prevents all geberic proxy-handlers. I suppose I need to write some article about reasoning for generic InsUpdRem flow handlig with itemId and historyID, including algorithms and methods and especially why this would be by my opinion a crucial point to succesfully build reliabale, stabil and effective pub/sub systems and especially content-based pub/sub systems for unreliable networks and IT services :) Propably what you missed there, I'd like to have either 'ver'sion or timestamp been _able to_ set by publisher, but not necessary required to be set by publisher. Would one like to publish on item with incorrect 'ver'sion in it, service should notify publisher about this. - Ville
