Re: [OT] Versioning and compatibility checking
Yeah, we have the same situation. It's essentially a schema compatibility integer. Perhaps a major and minor version would work where major versions have to match and minor versions are insignificant (e.g., for bug fixes) Yeah, that is also what I am thinking. At first I thought of having 4 version numbers for the client app, and 3 for the server, now I am thinking of sticking to 3 and 2. Thx, 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]
[OT] Versioning and compatibility checking
Hi all, 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). 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. It is not my intention at the moment to deal with server app - database compatibility. Besides, I believe this has been addressed in WOnder already, no? I have some ideas, but also some questions: 1. Does anyone do this, if so, can I have a look? 2. Anybody wants to share some general experience with this sort of stuff? 3. Any pointers to third party libraries with a similar purpose + recommendations? 4. Any design suggestions (if someone is interested, we can discuss this in more detail off list), or best practices? 5. Anything else? 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]
Re: [OT] Versioning and compatibility checking
On Jun 30, 2008, at 10:28 AM, Florijan Stamenkovic wrote: Hi all, 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. 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) It is not my intention at the moment to deal with server app - database compatibility. Besides, I believe this has been addressed in WOnder already, no? If you are referring to Migrations updating the DB at startup to match application-defined schema and some basic data massaging, yes, it does. I have some ideas, but also some questions: 1. Does anyone do this, if so, can I have a look? 2. Anybody wants to share some general experience with this sort of stuff? 3. Any pointers to third party libraries with a similar purpose + recommendations? 4. Any design suggestions (if someone is interested, we can discuss this in more detail off list), or best practices? Why off list? The more this type of thing is discussed on-list the more people may chime in with similar non-JC ideas. 5. Anything else? 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/webobjects%40avendasora.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: [OT] Versioning and compatibility checking
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]
Re: [OT] Versioning and compatibility checking
Hello Florijan; I use a compatibility integer that gets matched between the client and the server's base-endpoint. This works well for the situation where you have one or two pieces of (in my case JSON-RPC) client software, but as the number of different pieces of client software grows, it then calls for a roll-out of everything for each update to this compatibility integer. So far, I have not seen an easy solution to this issue, but have also not had the opportunity to invest any serious time into it because in my cases it is manageable. cheers. 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). 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. ___ Andrew Lindesay www.lindesay.co.nz ___ 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]
Re: [OT] Versioning and compatibility checking
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 (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]
Re: [OT] Versioning and compatibility checking
On 01/07/2008, at 6:39 AM, Andrew Lindesay wrote: Hello Florijan; I use a compatibility integer that gets matched between the client and the server's base-endpoint. This works well for the situation where you have one or two pieces of (in my case JSON-RPC) client software, but as the number of different pieces of client software grows, it then calls for a roll-out of everything for each update to this compatibility integer. So far, I have not seen an easy solution to this issue, but have also not had the opportunity to invest any serious time into it because in my cases it is manageable. Yeah, we have the same situation. It's essentially a schema compatibility integer. Perhaps a major and minor version would work where major versions have to match and minor versions are insignificant (e.g., for bug fixes) 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). 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. with regards, -- Lachlan Deck ___ 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]
