On 2/18/13 3:17 AM, Heiko Braun wrote:
I think you are comparing apples and oranges. Providing the subsystem
is
not a client responsibility and API level is not protocol level (as in
wire format) .
The question is if it's beneficial to decouple the client protocol from
the core management API or not. But this doesn't mean clients have to
provide the subsystem on their own. It's merely a design decision.
For instance when looking at the HTTP bridge for notifications, it might
be beneficial to leverage a subsystem decoupled from the core management
layer, that merely acts as an API client to the server internals. This
way we might have websocket notifications as an early preview for example.
If we design it to be a part of the core management layer, then it
probably depends on the availability of the undertow components. This is
the degree of coupling we could avoid.
Our intent is to switch the HTTP management layer over to undertow.
Hopefully in AS 8. So I don't see a benefit to implementing it using
some other tech in a subsystem. Seems we'd be better off devoting that
energy to making sure the undertow solution gets done.
But I don't see all benefits & drawbacks of both approaches
yet ...
On Feb 18, 2013, at 9:08 AM, Heiko W.Rupp <hrupp(a)redhat.com
<mailto:hrupp@redhat.com>> wrote:
> We need to have one implementation at the api level, that all clients
> can use. Of course writing internal subsystems is über-cool,
> but we should still consider people that want to write their client in
> e.g. perl.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat