Re: remote object persistence - client classes

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Jul 05 2006 - 14:52:48 EDT

  • Next message: Mike Kienenberger: ""Can't build a query for temporary id" after upgrade from 1.2B2 to 1.2RC2"

    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 <andru..bjectstyle.org> 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.
    >



    This archive was generated by hypermail 2.0.0 : Wed Jul 05 2006 - 14:53:18 EDT