Common Client/Transport [was Qpid and AMQP 1-0: Plans?]

[Rajith Attapattu <ra...@gmail.com>]

Several ideas/suggestions regarding the common client/transport was
highlighted on the "Qpid and AMQP 1-0: Plans?" email thread.
For my own benefit (and that of the community) I'd like to summarize these
ideas/suggestions in a separate thread to get a more focused discussion.
The presentation and links sent by Rafi is
here<https://cwiki.apache.org/confluence/display/qpid/Common+Client>.


The key ideas that emerged,

1. At what level is the common client/transport going to be ?
     1. Protocol Engine  only
     2. Protocol Engine + Messaging API
     3. Protocol Engine + IO
     4. Protocol Engine + Messaging API + IO
     5. Protocol Engine + Messaging API + IO + Threading

2. Are we going to target different levels (as indicated above) for
different language clients ?
    For example we could do something like,
       1. Java & C++ client - Protocol Engine only  (that is IO, threading
model and Messaging API is built using the native language)
       2.  Python, Ruby, Javascript, Perl, .NET - Option 5 with a thin
language specific veneer on top of it.

3. What languages will the common client/transport be available in ?
    1. Java - for maximum portability of the Java client
    2. C - (second most portable option after java)
    3. C++ ?
    4. Python ?

My personal preference is Java and C protocol engines.
In order to easily maintain and for perf reasons I am tempted to have a
Messaging API and IO module in C to be used by Python, Ruby, Perl...etc/

4. Multiple Version support.
    1. Will be have common protocol engines for 0.8,0.9 and 0-10 as well ?
    2. If not how are we going to support older versions ?

5. Multiple Protocol support.
    The high level API is protocol agnostic and if we go by the above
architecture we should be able to have multiple protocol engines under the
hood.
    Ex Stomp or XMPP.

6. Implementation strategies.
    1. How are we going to introduce these changes to the current code base
?
    2. How will the layering be for clients like JMS, WCF or even native
Java and C++ clients.
    3. How do we plan to support the native threading model etc..
This is probably separate topic on it's own, but wanted to mention here for
completeness.

7. Testing strategies.
    We should definitely try to have a cohesive testing strategy for the
clients and the broker.
    This is probably separate topic on it's own, but wanted to mention here
for completeness.

Regards,

Rajith.