On 29/06/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
Hi,
I have attached a design document (I hope Rupert will be pleased :)).
The aim is to quickly provide 0.10 support by maximizing code reuse. We
will then incrementally update the design and the code for improving
management/clustering/performance enhancement/backward
compatibility/AMQP API/etc.
I am sure you'll have some useful comments and ideas that will impact
this design. However, keep in mind that for now on I really aim at
maximizing code reuse.
Arnaud
Arnaud,
Thanks for putting that document together. I haven't been keeping up
with the 0_10 work as much as I'd like but with M2 coming to an end
I'll have to dive back in there. I would very much like to request
that we think about supporting 0_8 *and* 0_10 in the client code at
least. This could be by having two sets of classes below the model
layer such that the client can only speak one protocol at a time. This
would be beneficial for migrating existing customers to the newer
protocol. Deployed clients are generally harder to change then their
broker so if the client could support both protocols an incremental
upgrade could be possible.
As we are designing the changes for 0_10 I think it is important to
think about multiple protocol version support. Ideally going forward
from 0_10 the protocol (from what I understand) will not have such
radical changes as we have going from 0_8 to 0_10, as such supporting
0_11 etc from our next client should be one of our goals.
If we do decide to support 0_8 as well the next client we will of
course have to remember that the project has people using this
software in production. As a result we cannot just change our client
API. New functionality is easy to add but altering the behaviour of
existing methods will be extremely annoying to existing users. All
changes to existing APIs should be well documented and have the
ability to maintain their functionality in the selected protocol
version. Ideally current clients should be using the JMS interfaces so
reducing the change problem but we shouldn't assume this. As we move
forward with the implementation we could start to think about what
methods that are public in our client code that should actually be
public and part of any API we wish to put forward.
On Tue, 2007-06-19 at 15:41 +0100, Rupert Smith wrote:
> Presumably you mean for the Java? This is the Java version of a scope
> of work drawn up for the C++ by Gordon?
>
> It would be nice to see this grow into a reasonably clean 'design
> document' for the Java going forward to 0.10. I'm a big fan of the
> design first, code later approach, rather than trying to divy up work
> for such a complex thing on the basis of a high level summary. The
> result will be more coherent, I feel, if we get a chance to establish
> a reviewed design first. Nice work, and I think it will provide a very
> good framework for the Java F2F to work around.
>
> Can I suggest this forms the starting point of a Wiki for the 0.10
> design?
>
> Rupert
>
> 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
