Re: remote object persistence - client classes
On 7/5/06, Andrus Adamchik [EMAIL PROTECTED] wrote: The interesting part is processMessage(ClientMessage) - essentially all communications (including queries and updates) are done using a set of ClientMessages. The simplest message would be a QueryMessage that holds a NamedQuery. This is probably the place to start. To estimate the level of effort ... with my current knowledge of the framework it would probably take me 2-5 hours to rewrite a very basic context-less query client in Java . There may be language-specific caveats of course. And a learning curve... I still have to try out the existing remote object persistence myself: the possibility might present itself fairly soon, though. When I get a better feel for the speed of the entire concept and it's flexibility, I'll be able to comment more. As far as development is concerned, it seems to be that the way to go about it would be to define a minimum feature set, isolate the existing Java classes which implement this functionality in the ROP client and rewrite it class by class in something else. The first foreign language to implement such functionality would best be selected by the preferences of the people writing the code. Implementations in other would probably be much more straightforward, as the developers could litteraly try to rewrite a fairly small collection of classes in another language. Just thinking out loud... t..n.a.
Re: remote object persistence - client classes
BTW, I was trying to jumpstart this discussion on the dev list in the context of the related Summer of Code project: http://objectstyle.org/cayenne/lists/cayenne-devel/2006/07/0019.html We'll see if this generates wider interest. Andrus On Jul 7, 2006, at 4:06 AM, Tomi NA wrote: On 7/5/06, Andrus Adamchik [EMAIL PROTECTED] wrote: The interesting part is processMessage(ClientMessage) - essentially all communications (including queries and updates) are done using a set of ClientMessages. The simplest message would be a QueryMessage that holds a NamedQuery. This is probably the place to start. To estimate the level of effort ... with my current knowledge of the framework it would probably take me 2-5 hours to rewrite a very basic context-less query client in Java . There may be language-specific caveats of course. And a learning curve... I still have to try out the existing remote object persistence myself: the possibility might present itself fairly soon, though. When I get a better feel for the speed of the entire concept and it's flexibility, I'll be able to comment more. As far as development is concerned, it seems to be that the way to go about it would be to define a minimum feature set, isolate the existing Java classes which implement this functionality in the ROP client and rewrite it class by class in something else. The first foreign language to implement such functionality would best be selected by the preferences of the people writing the code. Implementations in other would probably be much more straightforward, as the developers could litteraly try to rewrite a fairly small collection of classes in another language. Just thinking out loud... t..n.a.
Re: remote object persistence - client classes
Actually clients written in other languages is one area that has a huge potential. And this is something I'd really like to explore. Current transport layer (Hessian) has support in many other languages, also a standard WS interface is being developed as a Summer of Code project. All this works already. Still what's lacking is an implementation of a client context in anything but Java. This is the biggest challenge. So if there is an interest in the community to write clients in .NET, PHP, Ruby, Python, (or maybe JavaScript/AJAX???), etc., let's do it. A full implementation would have to mirror cayenne-client- nodeps.jar, but it can start small, by providing only query API, and then grow to support relationships and updates. Thoughts? Comments? Volunteers? ;-) Andrus On Jul 5, 2006, at 11:46 AM, Tomi NA wrote: It just occured to me that cayenne remote object persistence might be the key to a level of interoperability that I need in a very, very heterogenous environent (i.e. my office) where people use Java, .net and php, depending on the project, programmer and legacy code. Is there any special reason not to have a number of templates, each generating client code for a specific language, so that both Java programmers and .net programmers could use the same jetty/tomcat/whatever powered web service as a nice wrapper arround the database? Forgive me if I sound so 1999, but there still exist people like me who have never written a WS so I have to ask. :) t.n.a.
Re: remote object persistence - client classes
Remote calls are done via a RemoteService interface (all low-level
details are handled by Hessian).
public interface RemoteService extends Remote {
RemoteSession establishSession() throws RemoteException;
RemoteSession establishSharedSession(String name) throws
RemoteException;
Object processMessage(ClientMessage message) throws
RemoteException, Throwable;
}
The interesting part is processMessage(ClientMessage) - essentially
all communications (including queries and updates) are done using a
set of ClientMessages. The simplest message would be a QueryMessage
that holds a NamedQuery. This is probably the place to start.
To estimate the level of effort ... with my current knowledge of the
framework it would probably take me 2-5 hours to rewrite a very basic
context-less query client in Java . There may be language-specific
caveats of course. And a learning curve...
Andrus
On Jul 5, 2006, at 2:15 PM, Tomi NA wrote:
On 7/5/06, Andrus Adamchik [EMAIL PROTECTED] wrote:
Actually clients written in other languages is one area that has a
huge potential. And this is something I'd really like to explore.
Current transport layer (Hessian) has support in many other
languages, also a standard WS interface is being developed as a
Summer of Code project. All this works already. Still what's lacking
is an implementation of a client context in anything but Java. This
is the biggest challenge.
Well, acording to my limited understanding of the framework, the misc.
client lib implementations would be completely free of the
database-specific code and the templates to generate client classes
should be fairly easy to write...so that leaves the context,
expression manipulation, query manipulation etc. There's some work to
be done there, but it might make cayenne very interesting to a whole
new audience:
Step 1: Welcome, to the new project wizzard. Please choose your
language: Java/C#/php/Ruby/Python/Perl/whatever.
Step 2: tell me where your database is and I'll set up the servlet
container and all cayenne-related files so that you can gat your hands
on the db data...
Step 3: go!
...or something along these lines. :)
So if there is an interest in the community to write clients in .NET,
PHP, Ruby, Python, (or maybe JavaScript/AJAX???), etc., let's do it.
A full implementation would have to mirror cayenne-client-
nodeps.jar, but it can start small, by providing only query API, and
then grow to support relationships and updates.
Thoughts? Comments? Volunteers? ;-)
Can you estimate the effort needed to produce the minimal
implementation for another language? I mean, I'd like to hear an
estimate of the size of the problem from someone who has a better idea
than I do of the existing cayenne code needed to implement the client.
I could go look at client-nodeps.jar, but I'm itching to get out of
the office and I'd still miss things important to notice. :)
Btw, the tutorial you linked to is very understandable. I only read it
- haven't implemented anything - but it's still an opinion.
Cheers,
t.n.a.
