On Mar 28, 2013, at 8:49 AM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
On 3/28/13 8:31 AM, David M. Lloyd wrote:
> On 03/28/2013 06:27 AM, Stuart Douglas wrote:
>>
>>
>> Darran Lofthouse wrote:
>>> On 28/03/13 11:04, Stuart Douglas wrote:
>>>> This is what we have been using to represent JBoss remoting URI's so
>>>> far. I do agree that is is a bit ambiguous.
>>>
>>> I am not sure if that has been a deliberate decision but apart from
>>> naming it has not really been that visible so far.
>>>
>>> I think what happened was the Remoting test suite had tests that had
>>> local and remote connection providers registered and then these names
>>> have stuck as new communication libraries have followed the test suite.
>>>
>>> So those names work when using the remoting APIs directly but are not so
>>> good once you are using an alternative API that is wrapping Remoting.
>>>
>>> I think whatever set of protocol names we choose they are going to need
>>> to be ones we can live with long term. The suggestions for Remoting JMX
>>> I think are fine, if we ever wanted pure http for JMX that could be a
>>> new library with a completely different protocol in the Service URL.
>>>
>>> However another question for 'ModelControllerClient' are we also sure
we
>>> will never want to add support for pure HTTP invocations?
>>
>> That is also a question that will need to be answered for EJB. I know
>> work is being done on a pure HTTP client, so we need to make sure that
>> there is no ambiguity there.
>>
>> Also if we have HTTP upgrade, why would we need a pure HTTP client
>> library? The only reason that I can think of is that if there are some
>> firewalls that block HTTP upgrade, but I am not really sure if that is
>> really a thing.
>
> It would be useful for thin (e.g. JS in the browser) clients which
> cannot do upgrade.
>
I haven't heard of any proposal to remove the existing REST-ish HTTP API
though.
Right I took pure HTTP client library as == ejb client over http talking
to a servlet that does EJB invocation (the pending EAP 6.x change). I don't
see any reason at all to have such a thing now that we support http upgrade
to remoting.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat