[jboss-as7-dev] HTTP Upgrade for AS8 Management

[Darran Lofthouse]

On 01/04/13 03:20, Stuart Douglas wrote:
> Ok, in that case I will name the protocol http-upgrade and https-upgrade.

Just thinking would http-remoting and https-remoting be better names?

After all we know we are upgrading from http / https but what are we 
upgrading to?

Taking the JMX example if you have 'http-remoting-jmx' this is JMX over 
Remoting, over HTTP.  If we decided to do JMX with a http upgrade but 
something different to Remoting we could just switch out the 'remoting' 
part from the name.

> I think we should probably also use this name in JMX, EJB client etc as
> well for consistency.

I agree - whatever we pick should be consistent across them all.
>
> Stuart
>
> Brian Stansberry 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.
>>
>> I do think it makes sense to be less ambiguous about the protocol names
>> for ModelControllerClient.Factory. Call them http-upgrade/https-upgrade
>> and that removes the ambiguity and leaves http/https available for the
>> future. It's just clearer anyway; otherwise people will incorrectly
>> assume "http" results in the client using the REST-ish API.
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>