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?
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?
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
