Re: [OT] Versioning and compatibility checking
Re: [OT] Versioning and compatibility checking
- Subject: Re: [OT] Versioning and compatibility checking
- From: David Avendasora <email@hidden>
- Date: Mon, 30 Jun 2008 17:25:15 -0400
On Jun 30, 2008, at 12:00 PM, Florijan Stamenkovic wrote:
I am about to implement a JavaClient focused versioning system to
evaluate the compatibility between the client and the server
during client startup. It is something that is a requirement in
our situation (JC + JBND apps, separated server client projects
etc).
What kinds of things are you trying to catch? Things like if a
invokeRemoteMethod("clientSideRequestFoo", keys[], values[]) is
called that it will verify that the clientSideRequestFoo with the
defined parameters actually exists? That would be nice.
Hm, I did intend to put some basic RMI stuff in, I guess I can put
this too. I am not sure how much benefit this will bring us. It will
not give us compile time checking when writing RMI code, and if you
try to invoke a non existing method you get a runtime exception
anyway... What would you like to gain by this? A suggestion for the
API?
I'm not really sure, it's just more of one of those things that it
would be nice to catch on launch instead of having to wait for someone
to stumble across it at runtime. But, If you are testing new code as
it is added, this is something that really shouldn't slip through the
cracks anyway. I think making sure the versions of each are compatible
is much more important and I'd certainly do that long before worrying
about this.
Note that I can make both the server and the client side, I think I
will provide a custom superclass to be used by the server side
JavaClient WO component, so a lot can be automated without the need
to afterwards do anything else except subclass the custom stuff.
Also note that this will be the starting point for WOJCKit, an
open source project where I plan to put this sort of generic stuff.
Wow. You are the Mike Schrag of JC! First JBND, now this? (no
offense to all the other Wonder/Wolips contributors)
I'm also hoping at some point to build something like an AppKit for
JBND, and WOJC. JBND is concerned only with binding GUI components
to data, WOJCKit will be concerned with client - server related
issues. AppKit (I guess it would need a different name) should be a
framework for building JC applications (architecture). Then I also
might implement a Derby or XML based local persistence for JBND
apps. That all together should give a nice base to start building
the *really* cool stuff on top ;)
Why off list? The more this type of thing is discussed on-list the
more people may chime in with similar non-JC ideas.
Fair enough. To visualize this it is important to know that the
WOJCKit will have at some point a division into three packages:
client, server, common. Client and server sometimes subclassing
common stuff. That said, here's my current versioning idea:
1. Have a "Version" class that is common to the server and the
client, have a client subclass of it: "ClientVersion"
2. Have Version contain the following info:
- app name and supported modules (modules being groups of Entities
that are interdependent)
- model versioning numbers (major, minor, correction)
- have it somehow try to automagically load version info from some
sort of a property file
3. Have some additional stuff in ClientVersion:
- client app versioning numbers (major, minor, correction, bug),
these would be in the ClientVersion
4. Have a string formatting / parsing support for all of the above
5. Provide RMI based functionality to compare the client and the
server, comparison criteria would be:
- app name and supported modules (server needs to support *at
least* all of the modules used by the client)
- model versioning numbers (only major and minor)
Comments?
Maybe in the context that you are talking about it would work just
fine, but I've been actually running into several problems with the
whole "common superclass" architecture for consolidating client- and
server-side business logic. Look for a more in-depth email about my
struggles in the next couple days. I'm running into things that I
think may make the benefits of a common class insignificant in
comparison with the complexities that you'd have to add to get those
benefits.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden