Folks: I appreciate the JSR effort. But slide is here and now. It works quite well as the foundation for a small scale, no non-sense CMS. I think the most urgent thing is to have better documentation. Next, I would suggest we think about the niche that slide will occupy. Let's face it, it is unlikely that slide will ever be able to compete against big boys like documentum in CMS space. Nor will it cut as a psudo file server. IIS and Apache already does it in a more scalable way. Just offering "WebDav" support is not going to cut it. I suspect that the current lack of ensuiacisim has a lot to do with this awkward place slide occupies. What is the poor kid "slide" going to do? I believe that the true strength of slide is in its flexibility. My interest is in security. I believe slide can be a foundation of a extreming flexiable, yet security repository. Think about single-sign-on for a federated repository set, think about fine grined authorization beyond the role-based model of j2ee, think of non-repuidiation of document. The list goes on and on.
This is just one example where slide's simplicity and flexibility truly shines. I am sure you can think of some other fine usages. Enough mumbling... Yuxin --- James Higginbotham <[EMAIL PROTECTED]> wrote: > I agree, I don't want to get too crazy, upset the > maintainers, and cause > a fork.. But, here are my thoughts: > > 1) That JSR's API should be a candidate for the > general Slide API to be > accessed via JMX, EJB, intraVM, etc. > 2) My understanding, based on talking with the lead > on the JSR, is that > no one has signed up for writing a webdav impl, but > that slide will be > adapting their webdav client to support it.. Not > sure if the kernel will > be refactored to support the same thing > 3) I'd expect that if we went down the path I > proposed, that we'd > concentrate on the JMX/EJB/VM implementation first, > since the webdav > client is pretty stable and easy to use as is > > Again, just throwing out my own ideas after working > with Slide for a few > months, in hopes of making it as top quality as the > rest of the Jakarta > projects. I wouldn't rank Slide with misc SF > projects, but I would say > that it ranks low in Apache's project list, esp > under the Jakarta > banner. I hope it gets better, as I think it has a > lot of potential and > there is definitely a gap in the market right now.. > You go from silly > script kiddie implementations in Java to Slide to > Tamino ($$ but with > lots of extras and support). > > James > > > -----Original Message----- > > From: Eelco Hillenius > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 12, 2003 4:18 PM > > To: Slide Users Mailing List > > Subject: Re: newbie question about slide future > > > > > > I think it's a bit too early to flame the Slide > maintainers, > > though I have not had a single answer to my posts > up to date. > > Compared to for example Maverick > (http://mav.sourceforge.net) > > that has at least one of its maintainers actively > supporting > > the mailing list, Slide seems to be doing rather > poor in > > promoting it's use. > > > > In reply to the proposal of James... I would > rather try to > > adapt some of the JSRs out there, most notably JSR > 170 (Java > > Content Repository). Check out > > > http://www.mail-archive.com/slide-dev%40jakarta.apache.org/msg > > 05587.html for the JCR contribution to Slide. It > looks like a > > nice enough API, especially considering it's an > initial > > import. The implementation is pretty basic > however. According > > to > http://jcrep-jsr.day.com/playground/en/schedule.html > > the community draft will be submitted in april > 2003 (that's 9 > > months later than the proposed scedule > > (http://www.jcp.org/en/jsr/detail?id=170), reason > for me to > > ask about the current status) and the final > release is > > planned for october 2003. It's probably a far > better idea to > > wait for this (and hopefully contribute to it) > than making a branch. > > > > Eelco Hillenius > > > > > > ----- Original Message ----- > > From: "James Higginbotham" > <[EMAIL PROTECTED]> > > To: "Slide Users Mailing List" > <[EMAIL PROTECTED]> > > Sent: Wednesday, March 12, 2003 10:13 PM > > Subject: RE: newbie question about slide future > > > > > > I've experienced the same thing.. Actually, I want > to put > > together a proposed architecture change and either > get commit > > access or just branch and be a rebel ;) Here is > what I'd like to see: > > > > 1) break the webdav client out into a separate > project - it > > should belong in commons, not in Slide > > 2) break the current slide codebase into 2 areas: > > a) Content server - a kernel that is capable of > doing > > versioned, workflow oriented content management > and could be > > the core of any CMS system > > b) Content API - access to the content kernel > via a number > > of gateways, including (but not limited to): EJB, > JMX, WebDAV/DeltaV > > 3) Create a basic CMS system on top of the > framework to prove that: > > a) it can be done and > > b) How to use the system > > 4) Enhance the docs to provide better information > from the perspective > > of: > > a) Extending the kernel (stores, interceptors, > etc) > > b) Writing to the framework using any of the > gateways > > c) Using/extending the example CMS system > > > > I originally started using Slide to build a CMS > for my > > church, and have found now that although nothing > better > > exists out there in the OSS world, this isn't as > easy as I > > thought it would be - mostly due to the lack of > support and > > poor code. For example, I want to lock a resource, > but to do > > that I have to copy/paste the logic from the > LockMethod.java > > that services webdav requests with 5 or 6 lock > calls. Why not > > have a LockCommand.java that is called from any > gateway, > > whether its from the webdav servlet (aka the > LockMethod > > class) or from my own Struts application (or for > that matter, > > even a JMX client within JBoss)? I've also seen > some postings > > of those trying to get the J2EE store to operate > properly > > within a UserTransaction and many failures > resulting of that, > > so some work on the stores themselves would be > required. > > > > Now, I've actually considered backing off and just > writing some > > OJB->MySQL code to do what I need, but knowing > that the > > bazaar approach > > is always "start from something that works and add > to it", > > I'd rather gain the knowledge of what the Slide > authors > > gained while writing it than stumbling over the > same problems > > again - even if I don't use the webdav gateway at > all. > > > > Thoughts? > > James > > > > > > > -----Original Message----- > > > From: Parker, Steve L. > [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 12, 2003 11:16 AM > > > To: 'Slide Users Mailing List' > > > Subject: RE: newbie question about slide future > > > > > > > > > I have experienced similar problems with getting > any help or > > > guidance.. I could get basically no response > from anyone. > > > > > > The resulting effect on a potential user is that > one becomes very > > > unsure whether it is a safe bet to use this > thing. One > > simple (or not > > > so simple) thing to do would be to have a more > understandable and > > > comprehensive documentation. There are several > different ways of > > > using Slide. For instance, use the WebDav > Servlet, or just use the > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
