On 05/18/2011 03:00 PM, Gordon Sim wrote: > 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.
ack, I think I've got that one, will post patch for alan to check > > 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. ack, that is what I implied. > >>> 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? no. will first provide patch that adds ownership. then will add QMF filter, or hit ted up for that. then add the acl check for owner in another patch. If others on the other hand want to help code.... well then .... regards Carl. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
