Awesome step guys.. I have been longing to see some work happening on SJ. I have a suggestion too, maybe this will make it into the wish list. Currently we can only open one archive at a time in a SJ Client. When I am working on many archives I have to instantiate separate client vms, which is definitely slower. Can we think of a multiple archives within one client instance ? Rob, would that be too much work ? Just a thought. I am kinda very busy at work and school otherwise I would have been more than happy to chip in.
Anin. On Thu, 27 Jan 2005 09:35:48 -0800 (PST), Robert MacGrogan wrote > 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 Thanks, Anin ******************************* Anin Mathen Sr. Software Engineer Pantheon Inc. Ph : 703-846-2232 http://www.pantheon-inc.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
