-
1. Re: Remoting 3: Decision time...
The following is the log of the chat David and I had on Monday.
trustin: Yes, but I didn't have a chance to reply yet.
trustin: I think the road map you mentioned there is pretty much same to what we've discussed so far.
trustin: The question would probably be .. 'is it ready to go CR?'
dmlloyd: probably not without more tests
dmlloyd: featurewise, yes
trustin: I think we can go CR first and write tests to cover the code and stablize it.
trustin: as long as it is stable featurewise
dmlloyd: it is, unless someone can think of anything I missed
trustin: I never think you missed something. :)
trustin: I think there are potential audiences for 3.0 anyway
trustin: It can be configured without JBossMC and we could provide a simple bootstrapper so that one can run it standalone quickly.
trustin: then we can attract users who want to use a flexible remoting layer for their application first and then try JBossMC integration if nice tutorial is provided.
dmlloyd: I have examples of how to configure it manually
dmlloyd: not many examples, but I do have examples :)
trustin: Yes. What I meant was a very simple 1-3 liner helper to attract people ;)
trustin: such a helper could cover most simple 'default' setup and some additional parameters that about 80% (?) users will need.
dmlloyd: the tricky part is that there is no standard protocol yet
dmlloyd: the multiplex handler is raw - no security
dmlloyd: things like classloading have been put off
trustin: Could we make the helper extensible so that a user can choose a transport and specify parameters dynamically (with reasonable default values)?
dmlloyd: sure, but I'm just saying that there really aren't any reasonable default values yet
trustin: the basic protocol? and we could change the default in 3.1 as soon as the SSH-based one is ready?
dmlloyd: I don't want people to use the basic protocol in production though. It mainly exists so that there's a model for other protocol implementations to follow
dmlloyd: basic protocol uses a connection per client rather than maintaining a connection independently of services and clients
trustin: hmm then who would be a target audience?
dmlloyd: people who want to use the API to begin defining services, I guess
dmlloyd: and clients
dmlloyd: while deferring connection implementation details
dmlloyd: the framework is designed to be used in an IoC environment and it shows, I think
trustin: but you don't want them to use the basic protocol in production - I'm confused.
dmlloyd: right, in production people should be using the multiplex protocol with some kind of security layer
dmlloyd: the thing is, all the features that would make R3 useful have been deferred to 3.1 or later
trustin: then the target audience for 3.0 would be limited to someone who is in the course of developing a service and will be in production after we release 3.1?
dmlloyd: yes, that was my conclusion
trustin: We have built R3 on top of flexible marshalling layer and XNIO-based scalable networking layer, so I think it will attract some people who wants to use it in a private network only? We could add SSL support for the basic protocol (via XNIO) in 3.0 though.
trustin: I might be missing something but from my understanding, current R3 has more features than plain RMI or other related technologies except for R2.
dmlloyd: well, it has more potential features anyway :)
dmlloyd: it's the most pluggable framework out there
dmlloyd: XNIO doesn't have SSL support currently
trustin: dmlloyd: Let's steal some from Netty
trustin: Shall I implement one? ;)
trustin: I actually think SSL is not even necessary to attract users with 3.0.
dmlloyd: I suppose what we need is a user guide
trustin: we could focus on SSH instead of SSL to save some time (not much)
dmlloyd: yeah, SSH will be a big priority
trustin: Yes. We need it otherwise going GA wouldn't help us attract people IMHO.
dmlloyd: maybe we could just live with not attracting many people with 3.0 :)
trustin: :)
dmlloyd: as far as SSL goes - I did not yet implement it because I wanted to be sure that the API is correct
dmlloyd: and there's a lot to know about how SSL can be used before being able to say that definitively
trustin: How SSL can be used?
dmlloyd: yes
trustin: to assure confidentiality of communication?
dmlloyd: special cases, unusual usage patterns etc.
trustin: from XNIO standpoint?
dmlloyd: yes
trustin: Ah I see.
dmlloyd: I want the API to be as simple as possible
trustin: We are talking about 3~4 projects when we talk about R3 :D
dmlloyd: yes :)
dmlloyd: if SSL support appeared in XNIO, R3 would be able to use it immediately
trustin: Yes, with no sweat :)
dmlloyd: but for streaming over a single channel I think we will need full SSH support, since it gives the ability to open independent channels
dmlloyd: though I could enhance the multiplex protocol to support independent channels as well
trustin: Agreed.
trustin: I guess the conversation so far seems to answer your questions in the forum pretty enough. Did we miss something?
dmlloyd: how shall we promote it
dmlloyd: I suppose that in the announcement I should make it clear what it can and cannot do
trustin: You mean promoting to JBoss.org developers or users?
dmlloyd: and explain that the target audience are those who want to start developing applications and services in anticipation of 3.1 and 3.2
dmlloyd: they're one and the same from my perspective :)
trustin: ah OK. :)
trustin: I like the idea about the announcement which shows the road map.
trustin: I think the road map should be shown in the front page of our project home page, too. -
2. Re: Remoting 3: Decision time...
The following is the consequent chat regarding this topic:
ron_sigal Do you think it's in a usable state? dmlloyd usable, sure dmlloyd I mean, you could use it dmlloyd er :) dmlloyd there's no security features to speak of dmlloyd no authentication, no authorization, no encryption dmlloyd also you have to wire all the pieces together by hand (like the samples demonstrate) ron_sigal Since it's not AS ready, this release would be for the general publc ... dmlloyd yes trustin Not so pretty but here's the log - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198393#4198393 ron_sigal Suppose you had an app based on R2. How hard would it be to upgrade to R3? ron_sigal If it's easy, it might attract more users ... trustin Perhaps rewrite where it depends on R2? dmlloyd you'd have to basically replace R2 with R3 - I think it would be a net subtraction of code dmlloyd but there would be code changes, probably substantial dmlloyd also it depends on *how* the app is using it ron_sigal So that might narrow the audience to new users ... dmlloyd wiring the pieces together to get a connection and services and so forth is actually quite a bit of boilerplate code dmlloyd but actually *using* it is very simple dmlloyd the intent is that a container would generally manage the wiring trustin new users and early adopters trustin or.. upgraders :) ron_sigal But it's not mc ready yet? trustin I thought it is now? dmlloyd you could deploy it in the MC using <bean> tags dmlloyd but I intend to have a separate XML schema for remoting deployments trustin ah, I see. dmlloyd tags to create endpoints, tags to set up connections and servers etc ron_sigal Do you think the boilerplate is easy to reproduce? I guess my question is: how steep is the learning curve? dmlloyd https://svn.jboss.org/repos/jbossremoting/remoting3/trunk/samples/src/main/java/org/jboss/remoting/samples/simple/MultiplexClientExample.java <- here's a trivial multiplex client dmlloyd I dunno, it's kind of a pain in my opinion dmlloyd but that's *correct* dmlloyd I expect you could do a quick-and-dirty version with a lot less messing around trustin the code is quite simple imo trustin many indented blocks make it look complicated at the first glance though. dmlloyd yeah dmlloyd everyone has their own style with dealing with resources - I like to use final variables + try/finally trustin IIRC, we didn't find a cool way to simplify this. trustin What about adding IoUtils.safeClose(Closeable... closeables) ? dmlloyd for 3.1 I'd like to have a negotiation protocol that can be used to configure things like marshalling ron_sigal Yeah, my first reaction was: that's scary. But upon reading it, it's not so bad, I think. trustin nvm, my suggestion doesn't work dmlloyd anyway I'd like to make at least a client simpler, if possible dmlloyd here's the server: dmlloyd https://svn.jboss.org/repos/jbossremoting/remoting3/trunk/samples/src/main/java/org/jboss/remoting/samples/simple/MultiplexServerExample.java dmlloyd actually a bit simpler, oddly :) trustin looks quite similar to the client side one dmlloyd a lot of it is the same. Either way, you're setting up an endpoint and a connection dmlloyd the server actually acts as a server in two senses: it acts as a TCP server to accept the multiplex connection, and it has a service registered as well which can be accessed from a remote client dmlloyd I could have put the service on the client I suppose trustin without modifying the current R3 but modifying the client side example? dmlloyd right trustin I see. Cool. dmlloyd multiplex just connects two endpoints. You could register many services on each end of the connection ron_sigal I think a user's guide is important. For people like me. :) dmlloyd yeah, I was thinking that maybe I should at least start a user guide before the 3.0 final release... ron_sigal +1 dmlloyd and go through and make sure the javadoc is complete trustin Assuming that 3.1 user guide will be based on 3.0 user guide dmlloyd yes, I think the user guide should live in its own trunk ron_sigal 3.0 could present general principles. trustin yeah that's a good idea. dmlloyd I don't want to tie user guide releases to code releases ron_sigal ?? dmlloyd I'd like to make sure that in the user guide, if something is only available, say, after 3.2, I'd say "In 3.2 or greater, you can frob the gibble using the new frobnicator blah blah" dmlloyd that way, corrections can make their way back :) dmlloyd otherwise I'd never release for fear of having an imperfect user guide *dmlloyd knows dmlloyd ron_sigal That sounds like the guide *is* tied to the release. Missing something. trustin hmm dmlloyd the latest user guide should always be available ron_sigal I like the "In 3.2 or greater, ..." dmlloyd if we bundle the user guide in trunk with the code, then we'll end up having to manage the user guide in branches as well ron_sigal Ah. dmlloyd I'd rather just keep it independent, and update the one on the website every, say, 2-4 weeks or something ron_sigal I misunderstood "tie". Cool. ron_sigal Yeah, I'm always updated a 2.2 and a 2.5 guide. ron_sigal updated -> updating trustin perhaps we could maintain the documentation in a different trunk/branch and use svn:externals? dmlloyd what would we use svn:external for? trustin at least we need to include the documentation in the distribution dmlloyd I see it as fully independent dmlloyd hm, I dunno dmlloyd we could download it as an artifact too trustin or just a URL? dmlloyd I don't know if it's really that useful including it right in the distribution dmlloyd might be more useful as a separate download trustin I see. yeah separate download makes more sense. dmlloyd well, getting 3.0 out leaves us with the 3.1 tasks to get going on dmlloyd management (JMX and JOPR), HTTP, SSH, compatibility layer dmlloyd those are the big items trustin Yes. dmlloyd a 16-week release schedule, and a 3.0.0.GA release in the week of Jan.12 would mean that we'd need to have CR1 by mid-april ron_sigal I started looking into an HTTP transport at one time ... trustin You mean 16 weeks to the first CR of 3.1? dmlloyd yes dmlloyd no dmlloyd 16 weeks from GA to GA trustin ah OK I miscalculated :) dmlloyd oh, the other important item is completing the AS integration, with a JCA RA ron_sigal When's Weston coming back? :) dmlloyd :) dmlloyd I don't even ever see him on IM anymore ron_sigal ah trustin I'm not sure we can finish all the stuff scheduled for 3.1 in 16 weeks. I just guess I need to try. trustin not saying negative nor positive. Just don't have a clue on this. ron_sigal We know dmlloyd is salivating over SSH. :) dmlloyd well, we'll tackle one thing at a time dmlloyd yeah, I've got SSH underway dmlloyd I figure I'll need to get XNIO-SSH 1.0.0.Beta or CR out by early Feb to get a working transport on top of it by april... trustin I guess we also need netty cr so that ron can work on http ron_sigal I tried to create an indirection layer so I could use different implementations, so I could get started without netty, probably. ron_sigal I had something that worked with HTTPUrlConnection and apache HttpClient, IIRC. trustin OK. Netty HTTP implementation is ready to go. I think you can get started with it now although it's alpha. ron_sigal ok, cool. ron_sigal I'll just start reading the R3 users guide. :) dmlloyd it'll probably take me longer to get docbook set up than it will take me to get the guide roughed out :) ron_sigal Maybe you can copy from R2? dmlloyd I'll probably just copy whatever ales did for the jbossmc user guide dmlloyd there's a new thing now dmlloyd it's all maven-based ron_sigal ah dmlloyd with the new look&feel and so forth trustin you might want to take a look at the customization I've done for NEtty user guide. trustin I figured out how to override the default settings and insert the version number dynamically etc etc. dmlloyd I see dmlloyd I think I will copy yours :) trustin :D ron_sigal trustin has the hacker gene. :) trustin lol dmlloyd I don't know if I need version numbers, but yours looks better than the jbossmc one
-
3. Re: Remoting 3: Decision time...
One thing I do want to do before the final release - I think that Transporters should be separate from the core. The reason is that I think it is more of a "beta" feature - there are many things that haven't been considered (like remote reference management, distributed GC, etc.) that should be considered before this feature is considered "stable". Also I'd want to find at least one or two users of the feature before releasing Transporters as stable.