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
