Marc, you make a good point about having to work against multiple servers. If we have a good SOAP API, then, you're right, we shouldn't have to change it. The problem is, the API is not necessarily all that good. And sometimes improving the functionality of existing features requires modifying the existing API.
...but ideally it shouldn't. Why don't we look to a reworked and simplified API for SJ 3 :)
One way limit the impact of backward compatability would be to have the client be backward
compatible but not the server. If you get the latest client, you'll be able to work against any
existing server. Or we could freeze the most significant API's, connect, get project object, get
file object, get file, check in, and check out. Or at least required future versions of the server
to always support the current API for those features.
You make a good case, Marc. I'll definitely consider what you're saying.
Thanks. The multi-version client could be kind of messy. Can't the server implement an "adapter" type mechanism where there can be multiple SOAP services attached to the server, implementing different versions of the API, or different "modules" to the API?
This would certainly require some API redesign but if the current model is constraining us in this regard, it means that something isn't right.
For example, currently we only need something like:
connect get folder get file object get file add file add folder check in check out create label move rename copy remove
...call this, say SJBasicServices.
Then in the future we sould add SJSearchServices... with:
set current filter clear current filter
...and then SJReportingServices with:
get checkout report for user get checkout report for folder
...and these, at the server, would just plug in to the existing code without screwing up the base functionality.
Then you can even have clients adapt their menu options based on the capabilies of the server. i.e. if there is no SJReportingServices SOAP interface available, View Checkout Report is disabled.
Surely this is a simple modular way to do things? Core APIs like get file etc should never need to change on the server, SJ's in it's 2nd major release after all - nothing much changes with the basic features, if it does, the parameter lists and contracts need to be updated to remove the possibility of breakage.
By the way, my first work on the 2.2 release will focus on speeding up SJ. I'm going to change SJ to use SAX to read XML files instead of DOM. This should have a pretty big impact, I think. And I'm going to switch SJ to use the latest version of Apache Axis. One change between Apache SOAP and Apache Axis is that AS uses DOM and AA uses SAX. Using SAX for all SOAP calls should speed up SJ significantly.
That sounds great. I would say, if possible, to use JDOM as it is so much more natural than DOM - it should be possible to plug in the SAX listeners to JDOM.
Cheers
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
