My 2 cents, 

I was watching that video tonight, is a great approach, assuming that we'll only use app engine for it, already mentioned in this thread.

So, we're discussing endpoints generation without app engine. We're assuming that our backend will be only Java right? So how could I do the same with torquebox and ruby? Can I generate client source code to ring endpoints on immutant? OpenShift doesn't run only Java, right?

http://tb-aerogear.rhcloud.com/ <- aerogear + torquebox + ruby

I would rather to go with well defined endpoints on the server side and build nice APIs to the client side, is just my opinion.



-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Wednesday, August 15, 2012 at 12:41 PM, Marko Strukelj wrote:

----- Original Message -----
If you had some schema describing what you can expect in the
result, you could use that to generate POJOs and code to
automatically mashal / unmarshal these. You can also wrap the
mechanics of HTTP calls away and after done with all that what you
have is just a class representing a remote service with methods
taking POJOS that wrap all the mechanics of the remote call and
return deserialized POJOs back.
A point to keep in mind is that code generation should be our
**last** resort - in a ideal world we have just one client library
that autodiscovers the rest via a single endpoint.

You mean that your javascript module has dependencies specified, and automatically downloads other javascript modules...
Or you mean that in java client you have a .jar that automatically downloads other jars? Sounds like module system and bootstrap code that harneses the module system to pull down all the code.

But how does that address hiding plumbing away from the developer? And productivity features like typesafety, and codecompletion that IDEs give you?
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev