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.
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. 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. --Rob --- Marc Palmer <[EMAIL PROTECTED]> wrote: > Robert MacGrogan wrote: > > Geez, still using a beta version :-) > > > > Yes, the incompatibility messages are a major annoyance. It should be > > possible in all future > > versions of SJ to add an SJ version value to the SOAP message (at least on > > connect) that will > > allow the server to tell if it's a compatible client. Then the server could > > send back a > message > > that makes sense. > > > > As for backward compatibility--this is not something I want to worry about. > > It is difficult > enough > > to add functionality to and improve SJ as it is. Look at how long it's > > taking me to get > rolling on > > 2.2 development. Adding a requirement that new servers must support old > > clients is, I think, > just > > too much to handle. Sometimes you really do need to change the API. (Look, > > for example, at > > Hibernate 3--not API compatible with Hibernate 2.) The previous APIs might > > really be lacking > and I > > don't want to limit myself like that. > > Fine... but such changes should happen on -major- versions only. It's > not fun if you have 3 different version SJ servers to work with and you > need 3 clients installed. > > There's no reason I can see, with a well designed SOAP API, that old > clients cannot continue to use the basic services in newer servers. I > think this is quite important, really... > > New features should be added as new SOAP services on top of the core > services. Isn't this possible? I think it would really make sense. > > > This may sound anti-user and maybe it is. But my response to that is that > > the client is free > and > > small and easy to download and install when necessary. > > As above, working with multiple SJ servers admin'd by different people, > is not fun. Imagine if SJ was used everywhere instead of CVS for open > source projects (wouldn't that be nice!). > > You'd need lots of different client versions to be able to work. That's > not required with CVS (for example), to my knowledge. > > > None of that excuses the ugly and confusing messages, however. That we will > > definitely fix. > > Yes please :) > > > -- > Marc Palmer [EMAIL PROTECTED] > > Wangjammers - Java, J2ME and Web Consultants > ~ http://www.wangjammers.org/ > > > > ------------------------------------------------------- > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- 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
