darkfiber
unread,Jun 29, 2009, 11:05:13 AM6/29/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to cometd-dev
Hello,
we've been using Jetty BayeuxClient for a while in several projects
and it works very well. Our Bayeux server has support for streaming
(both iframe and simple forever-response), so we needed a way to
extend the standard BayeuxClient to support HTTP streaming with the
forever-response technique. We ended up with adding another Exchange,
StreamingConnect, and several small changes in various parts of
BayeuxClient. These changes were needed to properly handle all
possible cases and retain compatibility with long-polling connects.
While this works, there is of course the problem that we had to
effectively fork a new version of BayeuxClient. It is not possible to
extend BayeuxClient.Exchange class from outside of the BayeuxClient,
because it is protected. And since BayeuxClient and Exchange
subclasses are tightly coupled, it is not possible to add new
exchanges without modifying the BayeuxClient on at least several
places.
Would it be possible (and feasible) to introduce an abstraction like
Transport, similar to the transport in server or JavaScript client?
Ideally with a Factory that takes care of instantiation of appropriate
transport instances. From my perspective, the goal should be to
decouple BayeuxClient from the concrete transport implementations
(that is, Exchanges) and make it easily extensible from outside. There
is no point in trying to completely hide Exchanges, because there is
already a dependency to Jetty HttpClient (which uses HttpExchanges),
but a simple factory pattern and several decoupling tweaks could be
added and would greatly improve the BayeuxClient.
We could make a simple prototype and post it for review, if there is
interest?
I'd greatly appreciate any feedback on this matter.