[wildfly-dev] HTTP Upgrade for AS8 Management

[Darran Lofthouse]

So just to be clear, you believe it should be 'remote' not 'remoting'?

Regards,
Darran Lofthouse.


On 02/06/14 17:42, David M. Lloyd wrote:
> On 03/28/2013 05:15 AM, Stuart Douglas wrote:
>> - ModelControllerClient.Factory.create() now allows you to specify a
>> protocol, which can be either remote, http or https.
>>
>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL
>> rather than the current service:jmx:remoting-jmx://
>
> Unfortunately I missed-slash-bungled this way back when, but we need to
> sort out our URI schemes.
>
> When we have multi-layer protocol going on, the URI scheme we should use
> is like this:
>
>     outer+middle+inner://
>
> where "outer" is the outermost protocol (e.g. "remote"), and "inner" is
> the innermost (not counting layer 3 and lower *unless* that figures
> directly in to the URI scheme; an example of this sub-case is
> "stratum+tcp" vs "stratum+udp").
>
> So we *should* have:
>
>     remote://           Direct Remoting-protocol connection
>     remote+http://      Remoting over HTTP upgrade
>     remote+https://     Remoting over HTTPS upgrade
>
> And (if these are even really needed; I think we dropped this
> distinction though maybe I'm wrong):
>
>     jmx+remote://       JMX over Remoting
>     jmx+remote+http://  JMX over Remoting over HTTP
>     jmx+remote+https:// JMX over Remoting over HTTPS
>
> The most common "de facto" function of hyphenation in a URI scheme is to
> be a separator for a two-word protocol, like "view-source" or "ms-help"
> etc.  The most common "de facto" function of using "+" is as I've
> described above, perhaps made most popular by Subversion's use.
>
> You may be wondering: Why not apply this to every single protocol we
> have?  And/or every single protocol in existence?  I think this goes
> beyond practicality - the point is to be unambiguous and consistent, and
> also align on the correct "remote" scheme name (we have a mix of
> "remote" and "remoting" today which is kind of confusing).
>
> Fixing this is not really a top priority obviously, but I would like to
> eventually unify our configuration on these scheme names (still
> supporting the old scheme names for compatibility of course).
>