I think that we can start right now safely working on the framing, session and execution layers that are common to the client and the broker (maybe the execution layer is slightly different). Those layer should not impact on our cluster, Message/Queue/DeliveryManager and management/monitoring design. Moreover I really see having those layer done as the main step toward providing 0.10 support.
Arnaud On Tue, 2007-06-19 at 16:01 +0100, Robert Godfrey wrote: > Yep, we need to think about management, and about security. > > At the F2F it would also be good to think about how clustering is > going to affect our design. > > -- Rob > > On 19/06/07, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > On 19/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > > I think we really want to examine our Message / Queue / > > > DeliveryManager / Subscription model as well ... this is not > > > necessarily driven by 0-10, just that the code is a bit "confused" > > > > > > -- Rob > > > > I would like to include management/monitoring of these items in the > > examination so that we can develop a cohesive solution. > > > > > On 19/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > > > > > Even if we have agreed on meeting in Glasgow sometime between the 21rst > > > > and the 23rdf of August, I would like us to establish a plan for > > > > migrating to 0.10. I have added a list of tasks for migrating to 0.10 > > > > (it is based on what Gordon has done for C++). It would be nice to put > > > > estimate on those tasks and also to allocate them to people (note that > > > > some tasks may be missing). More generally it would be good to know what > > > > people involvement for the 0.10 migration is. > > > > > > > > ==model:== > > > > * new query methods for exchange and binding (and possibly queue) > > > > * minor changes to method arguments etc > > > > - separation of 'auto-delete' from 'exclusive' in queue.declare > > > > - removal of responses and no-wait field from several methods > > > > - 'reject-unroutable' flag > > > > * new flow control for message transfer > > > > * new acking method for deliveries > > > > * dtx - expose basic functionality through client > > > > * changes to encoding of transfer > > > > > > > > ==execution layer:== > > > > * track execution mark for outgoing requests > > > > * manage execution mark for incoming framesets > > > > * generic correlation support (details still vague) > > > > > > > > ==session layer:== > > > > * session abstraction > > > > - Channel should be Session > > > > - channel exceptions are now session aborts > > > > - channel open and close should be altered > > > > - ack and hwm exchange > > > > * session management > > > > - maintain map of detached sessions, with timeouts > > > > - simple case: sessions destroyed on detach > > > > - failover: re-attach session to a channel on a new connection > > > > - manage requested timeout > > > > * replay buffer management > > > > - record all outgoing frames along with a sequence number > > > > - on receipt of an ack, delete as appropriate > > > > * session re-establishment & replay > > > > - implement session resumption (broker side only) > > > > - re-establish connection (client side only) > > > > - send any frames not seen by peer > > > > > > > > ==framing:== > > > > * new field table encoding (including lots of new value types) > > > > * new uuid type > > > > * new type for 'long sets' (for ack structures) > > > > * revised frame encoding > > > > * decoding from (& encoding to?) discontinuous data > > > > * revised architecture (chains, assembly of segments & framesets, > > > > memory management etc) > > > > > > > > > > > > > > > > > -- > > Martin Ritchie > >
