[jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Decision time...

[trustin]

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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198981#4198981

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198981