On 05/18/2011 06:33 PM, Carl Trieloff wrote:
On 05/18/2011 12:41 PM, Gordon Sim wrote:
On 05/18/2011 04:54 PM, Carl Trieloff wrote:
In working a patch to add ownership to the broker model for ACL, I see
that bindings are the only object we don't use encode and decode. This
meant that the first version of my patch required a change to the
encode/decode of binding in the store code. This is a break in
abstraction, where the broker should be providing the encode/ decode.
The same problem then also exists in the cluster for bindings, in
talking with Alan. (below)
The idea is to move to an encode/ decode in binding and the update the
signature of the MessageStore.h and remove the encode/ decode from the
inline code and add an interface method to the Recoverable objects.
Unless there are any objections, I'll proceed. My end game is to be
able to provide simpler ACL scoping for cloud usage of Qpid brokers, to
do so we need the identity of who created which objects.
I don't have any objection however important to explicitly call out
any changes that would break backward compatibility for recorded data
if that cannot be avoided.
correct, if we leave the decode / encode in the store code it may be
possible to make it backwards compat, but is more error prove for
cluster for example. This change will break compat for binding records
on the store, but will allow all future changes to be compat, and not
impact the cluster, because we have centralized the encode and decode
for bindings
The cluster doesn't use the encode/decode for queues either. If you are
adding new data to that stored for bindings (or indeed any other object)
- e.g. an owner - then that will very much affect the cluster.
Again, I'm not necessarily objecting, just raising issues to be aware of.
It will still however be possible to read an old Store, and forward
migrate based on the jrnl version if that is desired.
Reading an old store is essentially what I had in mind. I.e. ideally
upgrade will not require you to discard previously stored data.
It would also be important to share the design around ACL changes.
Again backward compatibility is relevant but even more critical is a
well thought out (and well described) permissions model. What we have
at present seems quite ad hoc already and we don't want to exacerbate
that.
All ACL work I have in mind will be backwards compat. and so far not
introducing more ACL syntax, just getting the impl behind the owner tag
that is already defined on the wiki etc, which simplifies may ACL's
Excellent, do you have a URL for the details?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
