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

Yes. On 06/02/2014 11:46 AM, Darran Lofthouse wrote: > 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). >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >