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.
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> 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.