And welcome back to you, too, Marc. I love your forthrightness and directness. Let's get this party started!
RE: JIRA: If you can get something set up I will declare it the official issue tracker for this release cycle. RE: Which branch to work off of: Timo, I'd like to go ahead and to a new client release on the 2.1 branch. I think I'm going to need to make a bug fix or two to get Brian's Eclipse plugin working, and I'd like to make that available asap. Your client changes all sound relatively small in scope, so I think we can plan on lumping your changes in with my bug fixes and plan on having a 2.1.0.1 (or whatever) release in the not-too-distant future. DST Issue: Marc, the problem with this bug is that it does not happen to everyone. I had no trouble at all moving from DST to ST and back this year. I really don't know what this issue is there, so this problem will be very hard to debug and fix. But let's give it a shot nonetheless. GUI Bugs: There are several. The sortable tables definitely get screwed up sometimes. And SJ needs to get better about making its actions more transactional so you don't get a screwy situation like the one you described. And wouldn't a cancel button on time-consuming processes be nice? Server Freakout: This problem at least has the virtue of being easily fixed. The whole lock file system is, to say the least, fragile. The only reason that system exists is as a failsafe in case you have two instances of SJ server pointing to the same archive, or, in case SJ gets very confused and tries to cache the same file or folder twice. Perhaps there's a better way to handle this whole thing. File Info At Folder Level: The idea of showing checkout status, and local file version status at the folder level is very very good. Also, showing directories that might need to be added would be good. And a Folder Properties button to at least show you the folder id would sometimes come in handy. Performance Improvement: I have some ideas on this subject. SJ does an awful lot of DOM parsing on the server side. All of that could easily be swapped to SAX (it's all very simple stuff, really) and direct string manipulation. I think this would buy us some time. The SOAP bottleneck remains. I've done a lot to streamline the SOAP message. One option is to try a new SOAP tool. The version of Apache SOAP SJ uses is pretty old. Perhaps we should try running it with Axis and see if that helps. Plugins: There's already a pretty thorough server-side plugin architecture. There's a very weak plugin architecture on the client side. The old 2.1.1 client branch was an effort to improve client-side plugin support. The only problem with the server-side plugins is that the API is not as well documented or advertised as it could be. Abstraction of Data Storage: I'm not very interested in this one. One of the things I really like about SJ is the filesystem storage of meta data. But I could see that some might want to use a DB, and it probably would not be that onerous to abstract this stuff. The original architecture had this idea built in, but there are a number of places where xml filesys storage are assumed in the code and these will have to be fixed. More to come soon . . . --Rob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
