On 12/3/09 9:56 AM, Ville Varis wrote: > > > On Thu, Dec 3, 2009 at 6:37 PM, Peter Saint-Andre <[email protected] > <mailto:[email protected]>> wrote: > > On 12/3/09 12:34 AM, Ville Varis wrote: > > > > > > On Thu, Dec 3, 2009 at 6:49 AM, Peter Saint-Andre > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > http://xmpp.org/extensions/tmp/xep-0060-1.13.html > > > > The data versioning stuff is here: > > > > http://xmpp.org/extensions/tmp/xep-0060-1.13.html#versioning > > > > > > "MUST NOT be accepted by the service from the publisher," > > > > This one makes me feeling I have to use some open source > implementation > > to make reliable service and to change this part by myself right > to the > > code. > > > > In node level I think this requirement is ok, not in Item level. > > I'm glad we agree about the node level, at least. :) > > > Serviveces A and B are equivalent, > > What does that mean? IMHO no two pubsub services can be identical, or > maintain the same information. > > > Maintain exactly same information flow. > > Typically back-ends connected to same datasource system/to same database. > > Or A and B being front-ends for original service to avoid load for > original one, and to allow scalability through front-end proxies. (For > some solutions removes the need for clustered solution in full) > > > > > Service A publishes ItemID a1, with Ver a123 > > Service A publishes ItemID a1, with Ver a124 > > > > Service B publishes ItemID a1, with Ver b123 > > Service B publishes ItemID a1, with Ver b345 > > But an ItemID is unique only within the context of a given node at a > given service. ItemID a1 at NodeID foo on Service A != ItemID a1 at > NodeID bar on Service B. > > > Subscriber S receives ItemId a1 from A and B in random order, how the > > subscriber should decide, which one is the correct one to use? > > > > Subscriber S changes it's subscription from A to B and reqeust all > items > > from which version? (from the beginning) > > > > Proxy server Pr acts as subscriber to A and B and as publisher to it's > > clients. Pr receives a1 from A and B, when is there time to update > data > > in Pr and to publish updates? > > > > And yes, I can do this by de-serialaising data part, which should > not be > > the case by my opinion, as this can be handled well-defined in > metadata > > part. > > > > Can it be, > > "Items 'ver' can set by publisher..." > > s/can/MAY/ > > You're trying to maintain information coherence across different pubsub > services, which seems like a really hard thing to do. However, I can see > circumstances in which it's OK for the publisher to specify the version, > so we might want to relax the MUST to a SHOULD on the service-side, and > say that the publisher MAY specify the item version (but not the > versioning for the whole node). > > > It's not so hard at all - and I'll proof it some point, needs some > background documentation to be polished. > > And I really would priciate that change, as it'll not block the future > changes like MUST would do.
The text in my working copy now reads: ### The 'ver' attribute is a string that identifies a given version of the collective items published at a node, or of a particular item. The value of a node-level version identifier MUST be generated only by the service, MUST NOT be accepted by the service from a publisher. The value of an item-level version identifier MAY be accepted by a service from a publisher, but if not included SHOULD be generated by the service. Version identifiers MUST be treated by subscribers as opaque, but MAY have meaning to publishers. Any appropriate method can be used for generating version identifiers, such as a hash of the published data or a strictly-increasing sequence number. ### Updated here: http://xmpp.org/extensions/tmp/xep-0060-1.13.html#versioning Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
