[DISCUSS] - camel-websocket component

[Claus Ibsen-2]

Hi

In Camel 2.10 we introduce a new component: camel-websocket.
Its currently based on Jetty, and thus requires jetty to be used.

In recent time the component was enhanced to support SSL with websocket as
well. That change brings in a lot of code that was
copied directly from the existing camel-jetty component.

So I wonder if we should consider

1)
Merge the code from camel-websocket into camel-jetty, as its all Jetty
based.
This avoid duplicated code,
This allows to share port numbers with http services and websocket.
Currently that is not possible as its 2 different components.

2)
Change the component name from websocket, so its part of jetty, eg

from("websocket:foo")
    becomes
from("jetty:ws:foo")

The current jetty component supports
- http
- https

So adding websocket is a matter of having
- ws
- wss

3)
In the future there will be other websocket implementations/components in
Camel. For example the Atmosphere framework seems to be a great framework
for that. As well with future releases of the JEE spec may introduce
websocket support from a spec point of view.
So having camel-websocket that is tied to Jetty seems to tie the "generic"
websocket name to a specific implementation (jetty).



Any thoughts?



--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[Charles Moulliard]

Hi Claus,

I completely agree on your proposition as we reuse pieces of code between
the different (same) camel components (jetty, websocket but also cometd) as
they increase "maintenance" costs.

Point 1) --> +1 to merge camel-jetty, camel-websocket and camel-cometd

The most important thing will be to reuse code of websocket as it supports
to register in a camel context a Jetty Application Server but with
different servlets (acting as producer or consumer or producer/consumer).
This is not the case for camel-cometd and camel-jetty

I would like also to propose that we include camel-cometd component as it
uses also jetty but for cometd bayeux protocol. Moreover, it provide
additional feature like CORS which is really important for
websocket/cometd. This is why I have created a ticket to also support CORS
in websocket (https://issues.apache.org/jira/browse/CAMEL-5354).

Agreement should be find between different components to adopt the same
Jetty version (7.5.4 or 8.1.3 for websocket support)

Point 2) --> +1 : jetty:protocol where protocol = ws, wss, cometd, cometds,
http, https
Point 3) --> +1 : As we plan to develop in a near future camel-atmosphere,
camel-vertx, camel-nodejs components to support different IO architecture

Regards,

Charles Moulliard

Apache Committer

Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard


On Mon, Jun 11, 2012 at 11:38 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> In Camel 2.10 we introduce a new component: camel-websocket.
> Its currently based on Jetty, and thus requires jetty to be used.
>
> In recent time the component was enhanced to support SSL with websocket as
> well. That change brings in a lot of code that was
> copied directly from the existing camel-jetty component.
>
> So I wonder if we should consider
>
> 1)
> Merge the code from camel-websocket into camel-jetty, as its all Jetty
> based.
> This avoid duplicated code,
> This allows to share port numbers with http services and websocket.
> Currently that is not possible as its 2 different components.
>
> 2)
> Change the component name from websocket, so its part of jetty, eg
>
> from("websocket:foo")
>    becomes
> from("jetty:ws:foo")
>
> The current jetty component supports
> - http
> - https
>
> So adding websocket is a matter of having
> - ws
> - wss
>
> 3)
> In the future there will be other websocket implementations/components in
> Camel. For example the Atmosphere framework seems to be a great framework
> for that. As well with future releases of the JEE spec may introduce
> websocket support from a spec point of view.
> So having camel-websocket that is tied to Jetty seems to tie the "generic"
> websocket name to a specific implementation (jetty).
>
>
>
> Any thoughts?
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

This does make a lot of sense to me.   websocket is really a standard for
which there could be multiple implementations.  Thus, the component name
really should be the implementation, not the standard.   Otherwise you get
into the whole "camel-http" issue again of having multiple things that COULD
be implementing it.  

So +1 for merging into Jetty from me.  

Dan



On Monday, June 11, 2012 11:38:15 AM Claus Ibsen wrote:

> Hi
>
> In Camel 2.10 we introduce a new component: camel-websocket.
> Its currently based on Jetty, and thus requires jetty to be used.
>
> In recent time the component was enhanced to support SSL with websocket as
> well. That change brings in a lot of code that was
> copied directly from the existing camel-jetty component.
>
> So I wonder if we should consider
>
> 1)
> Merge the code from camel-websocket into camel-jetty, as its all Jetty
> based.
> This avoid duplicated code,
> This allows to share port numbers with http services and websocket.
> Currently that is not possible as its 2 different components.
>
> 2)
> Change the component name from websocket, so its part of jetty, eg
>
> from("websocket:foo")
>     becomes
> from("jetty:ws:foo")
>
> The current jetty component supports
> - http
> - https
>
> So adding websocket is a matter of having
> - ws
> - wss
>
> 3)
> In the future there will be other websocket implementations/components in
> Camel. For example the Atmosphere framework seems to be a great framework
> for that. As well with future releases of the JEE spec may introduce
> websocket support from a spec point of view.
> So having camel-websocket that is tied to Jetty seems to tie the "generic"
> websocket name to a specific implementation (jetty).
>
>
>
> Any thoughts?

[Christian Mueller]

+1 from my point of view.

Christian

Sent from a mobile device
Am 11.06.2012 18:52 schrieb "Daniel Kulp" <[hidden email]>:

>
> This does make a lot of sense to me.   websocket is really a standard for
> which there could be multiple implementations.  Thus, the component name
> really should be the implementation, not the standard.   Otherwise you get
> into the whole "camel-http" issue again of having multiple things that
> COULD
> be implementing it.
>
> So +1 for merging into Jetty from me.
>
> Dan
>
>
>
> On Monday, June 11, 2012 11:38:15 AM Claus Ibsen wrote:
> > Hi
> >
> > In Camel 2.10 we introduce a new component: camel-websocket.
> > Its currently based on Jetty, and thus requires jetty to be used.
> >
> > In recent time the component was enhanced to support SSL with websocket
> as
> > well. That change brings in a lot of code that was
> > copied directly from the existing camel-jetty component.
> >
> > So I wonder if we should consider
> >
> > 1)
> > Merge the code from camel-websocket into camel-jetty, as its all Jetty
> > based.
> > This avoid duplicated code,
> > This allows to share port numbers with http services and websocket.
> > Currently that is not possible as its 2 different components.
> >
> > 2)
> > Change the component name from websocket, so its part of jetty, eg
> >
> > from("websocket:foo")
> >     becomes
> > from("jetty:ws:foo")
> >
> > The current jetty component supports
> > - http
> > - https
> >
> > So adding websocket is a matter of having
> > - ws
> > - wss
> >
> > 3)
> > In the future there will be other websocket implementations/components in
> > Camel. For example the Atmosphere framework seems to be a great framework
> > for that. As well with future releases of the JEE spec may introduce
> > websocket support from a spec point of view.
> > So having camel-websocket that is tied to Jetty seems to tie the
> "generic"
> > websocket name to a specific implementation (jetty).
> >
> >
> >
> > Any thoughts?
>

[Johan Edstrom-2]

+1


On Jun 12, 2012, at 3:56 PM, Christian Müller wrote:

> +1 from my point of view.
>
> Christian
>
> Sent from a mobile device
> Am 11.06.2012 18:52 schrieb "Daniel Kulp" <[hidden email]>:
>
>>
>> This does make a lot of sense to me.   websocket is really a standard for
>> which there could be multiple implementations.  Thus, the component name
>> really should be the implementation, not the standard.   Otherwise you get
>> into the whole "camel-http" issue again of having multiple things that
>> COULD
>> be implementing it.
>>
>> So +1 for merging into Jetty from me.
>>
>> Dan
>>
>>
>>
>> On Monday, June 11, 2012 11:38:15 AM Claus Ibsen wrote:
>>> Hi
>>>
>>> In Camel 2.10 we introduce a new component: camel-websocket.
>>> Its currently based on Jetty, and thus requires jetty to be used.
>>>
>>> In recent time the component was enhanced to support SSL with websocket
>> as
>>> well. That change brings in a lot of code that was
>>> copied directly from the existing camel-jetty component.
>>>
>>> So I wonder if we should consider
>>>
>>> 1)
>>> Merge the code from camel-websocket into camel-jetty, as its all Jetty
>>> based.
>>> This avoid duplicated code,
>>> This allows to share port numbers with http services and websocket.
>>> Currently that is not possible as its 2 different components.
>>>
>>> 2)
>>> Change the component name from websocket, so its part of jetty, eg
>>>
>>> from("websocket:foo")
>>>    becomes
>>> from("jetty:ws:foo")
>>>
>>> The current jetty component supports
>>> - http
>>> - https
>>>
>>> So adding websocket is a matter of having
>>> - ws
>>> - wss
>>>
>>> 3)
>>> In the future there will be other websocket implementations/components in
>>> Camel. For example the Atmosphere framework seems to be a great framework
>>> for that. As well with future releases of the JEE spec may introduce
>>> websocket support from a spec point of view.
>>> So having camel-websocket that is tied to Jetty seems to tie the
>> "generic"
>>> websocket name to a specific implementation (jetty).
>>>
>>>
>>>
>>> Any thoughts?
>>

[Jean-Baptiste Onofré]

+1

Regards
JB

On 06/11/2012 11:38 AM, Claus Ibsen wrote:

> Hi
>
> In Camel 2.10 we introduce a new component: camel-websocket.
> Its currently based on Jetty, and thus requires jetty to be used.
>
> In recent time the component was enhanced to support SSL with websocket as
> well. That change brings in a lot of code that was
> copied directly from the existing camel-jetty component.
>
> So I wonder if we should consider
>
> 1)
> Merge the code from camel-websocket into camel-jetty, as its all Jetty
> based.
> This avoid duplicated code,
> This allows to share port numbers with http services and websocket.
> Currently that is not possible as its 2 different components.
>
> 2)
> Change the component name from websocket, so its part of jetty, eg
>
> from("websocket:foo")
>      becomes
> from("jetty:ws:foo")
>
> The current jetty component supports
> - http
> - https
>
> So adding websocket is a matter of having
> - ws
> - wss
>
> 3)
> In the future there will be other websocket implementations/components in
> Camel. For example the Atmosphere framework seems to be a great framework
> for that. As well with future releases of the JEE spec may introduce
> websocket support from a spec point of view.
> So having camel-websocket that is tied to Jetty seems to tie the "generic"
> websocket name to a specific implementation (jetty).
>
>
>
> Any thoughts?
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Claus Ibsen-2]

Hi

I have logged a ticket about this
https://issues.apache.org/jira/browse/CAMEL-5364

I don't think we got the time to work on this now. So I have scheduled it
for 2.11.
Also I can see that camel-websocket needs to mature a bit more, for example
the last commit by Charles is a bit "hacky".
And I dont want to bring instability into the current camel-jetty component
if we do this in a rush.

And we owe the community to get Camel 2.10 out which has *Java 7* support.

Any thoughts?


On Mon, Jun 11, 2012 at 11:38 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> In Camel 2.10 we introduce a new component: camel-websocket.
> Its currently based on Jetty, and thus requires jetty to be used.
>
> In recent time the component was enhanced to support SSL with websocket as
> well. That change brings in a lot of code that was
> copied directly from the existing camel-jetty component.
>
> So I wonder if we should consider
>
> 1)
> Merge the code from camel-websocket into camel-jetty, as its all Jetty
> based.
> This avoid duplicated code,
> This allows to share port numbers with http services and websocket.
> Currently that is not possible as its 2 different components.
>
> 2)
> Change the component name from websocket, so its part of jetty, eg
>
> from("websocket:foo")
>     becomes
> from("jetty:ws:foo")
>
> The current jetty component supports
> - http
> - https
>
> So adding websocket is a matter of having
> - ws
> - wss
>
> 3)
> In the future there will be other websocket implementations/components in
> Camel. For example the Atmosphere framework seems to be a great framework
> for that. As well with future releases of the JEE spec may introduce
> websocket support from a spec point of view.
> So having camel-websocket that is tied to Jetty seems to tie the "generic"
> websocket name to a specific implementation (jetty).
>
>
>
> Any thoughts?
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[Babak Vahdat]

Hi

+1 to postpone this for 2.11 and bring the 2.10 release asap out the door, as I think we're now in a good shape for this (mostly because of your own hard work :-) )

BTW as I've already mentioned by the "[DISCUSS] - Apache Camel 2.10 release" thread there are still tests being commented out:

    org.apache.camel.component.websocket.WebsocketComponentTest

which is a bit "ugly" as well. If no volunteer, I could try to fix them but not before this weekend.

Babak

[Charles Moulliard]

Babak,

Maybe the two tests commented could be removed as they are coming from
initial upload when the code was mainly based on WebSocketComponent and not
really using WebSocket Endpoint. I have put them in comment as I haven't
had the time to think if we should keep them or not (was pretty busy last
weeks for client consultancy)

Regards,

Charles

On Wed, Jun 13, 2012 at 9:54 AM, Babak Vahdat
<[hidden email]>wrote:

> Hi
>
> +1 to postpone this for 2.11 and bring the 2.10 release asap out the door,
> as I think we're now in a good shape for this (mostly because of your own
> hard work :-) )
>
> BTW as I've already mentioned by the "[DISCUSS] - Apache Camel 2.10
> release"
> thread there are still tests being commented out:
>
>    org.apache.camel.component.websocket.WebsocketComponentTest
>
> which is a bit "ugly" as well. If no volunteer, I could try to fix them but
> not before this weekend.
>
> Babak
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-camel-websocket-component-tp5714283p5714404.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

[Babak Vahdat]

Hi

all of the 9 @Test by WebsocketComponentTest are now fixed and enabled again.

Babak

Charles Moulliard wrote

Babak,

Maybe the two tests commented could be removed as they are coming from
initial upload when the code was mainly based on WebSocketComponent and not
really using WebSocket Endpoint. I have put them in comment as I haven't
had the time to think if we should keep them or not (was pretty busy last
weeks for client consultancy)

Regards,

Charles

On Wed, Jun 13, 2012 at 9:54 AM, Babak Vahdat
<[hidden email]>wrote:

> Hi
>
> +1 to postpone this for 2.11 and bring the 2.10 release asap out the door,
> as I think we're now in a good shape for this (mostly because of your own
> hard work :-) )
>
> BTW as I've already mentioned by the "[DISCUSS] - Apache Camel 2.10
> release"
> thread there are still tests being commented out:
>
>    org.apache.camel.component.websocket.WebsocketComponentTest
>
> which is a bit "ugly" as well. If no volunteer, I could try to fix them but
> not before this weekend.
>
> Babak
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-camel-websocket-component-tp5714283p5714404.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>