OK, time to add my two small fractional currency units...

1) at least 99.9% of our users will use the standard JMS API and this
will be sufficient for their needs
2) forcing people to use commons configuration with an xml or
.properties file is a *terrible* idea.  We should be *removing*
dependencies not adding to them.
3) the client code needs to be modularized and clearly separated into
layers for maintenance reasons.
4) if people want to use advanced AMQP features they are likely
writing a new application to interact with other AMQP clients; not
using Qpid in a situation where they could replace with another JMS
provider.

My view:

We should have an API which mirrors the AMQP protocol.
We should not currently publicise or recommend its use as the protocol
is in too great a state of flux
Our JMS implementation should be written in terms of our AMQP API;
rather than randomly peopulating it with bits of code that go directly
to the framing level.



Every dependency on an external library that we add is another
(possibly insurmountable) barrier that we add for a project to adopt
qpid.  This is *particulalry* true of dependencies on common libraries
which are not 100% compatible between all released versions (this
applies to commons configuration and log4j); since these are
*precisely* the libraries that they likely already rely on but at a
different release number.  Assuming that a client application has
access to a filesystem to read configuration data is also a huge
mistake.


Overall - as I think Thomas pointed out - the client code is a bit of
a mess.  I support the idea of a refactoring, of breaking the code
into seperate layers, of one of those layers being an AMQP API.  I
would expect each layer to be in its own package.  By its very nature
this will make the API public.

For the very reasons that Robert states about protocol flux I would
not spend much time trying to expose advanced AMQP features through
the JMS API... where is the demand?  I would revisit this decision
once the protocol has reached v1.0.

Thoughts,
Rob

Reply via email to