Hi!

Great that there is some traffic again, I was afraid slide might be dying.

I added my 2 cents inline:

> -----Original Message-----
> From: Eric Johnson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 13, 2005 23:46
> To: Slide Developers Mailing List
> Subject: Re: project direction
> 
> 
> Paul Hussein wrote:
> 
> > Thanks for the comments
> >
> > As far as the client goes, I was thinking more of a client 
> that gives 
> > direct access like webdrive does, but with editing of acl's and 
> > searching maybe like google desktop, all built-in to the windows 
> > desktop, so you could map a network drive to a repoitory, 
> search it, 
> > click on a file and set the acl's.
> 
> I don't know how many of us I speak for,

Speaking for me!

> but one reason for 
> working in 
> the Java world is to decouple us from the platform.  But that is 
> slightly off topic.
> 
> Back in Java land, a "client" might make sense, either as an 
> extension 
> to Commons-VFS (curious, that project already has webdav:// 
> support), or 
> say, as an extension to the Eclipse framework, and/or as a 
> NetBeans plugin.

There is already a very good eclipse plugin: 
http://www.s-und-n.de/sunshine/ccos/de/produkte/english/webdavpilot
Funnily, the newest version is only announced on the german page 
http://www.s-und-n.de/sunshine/ccos/de/produkte/webdavpilot, meaning version 
0.3.3. This one "does" ACLs, you can also modify the directory structure and 
modify properties. The new version also does version diffs. Search is still 
only "planned" though.
You can get it here: 
http://www.s-und-n.de/sunshine/download2/de/webdavpilot0.3.3.zip

> 
> For one of our applications, I've done work using the Slide 
> client side 
> libraries to write a substitute for using a version control system.  
> Although I cannot contribute that code to a project (nor might anyone 
> want to look at it!), it does point the way to interesting 
> client side 
> applications.

There are lots of ways to use a webdav server like slide, not only through the 
client api. However I think the reason why many people have discontinued 
working on slide and might have switched to jackrabbit is that slide is a big 
monster inside. I don't know to what extend this is so with jackrabbit, but 
that one is still growing, so people can have more influence on how to "do it 
right".

In my opinion, people working on/with slide should probably focus on the 
usability aspect from the server side. Also, while slide is sort of a reference 
implementation, it does need to be fast, which is simply not the case right 
now. DASLs, the feature we use most, is slow as heck, even in the JDBCStore. 
I've added some features to spice up the lucene based dasls from the trunk a 
little and streamline the whole basicsearch stuff. I've already submitted a 
patch, but I have to clean it up a bit more, which is not so easy with my 
current workload...

In any case, I think that since slide is pretty mature, we should focus on 
streamlining, meaning speed optimizations and configuration tools. It would be 
great to have a JMX console for the domain for hot configuration, some scripts 
or so to install slide, maybe bundle jetty in the source like cocoon does it 
for a quick test drive feature and maybe even as the main deployment platform, 
things like that. Clients are nice, but like people said before, they mostly 
exist.

Another nice thing would be to be able to use slide to "webdav-enable" your own 
servlet application. This would be nice for people who are building a web 
application and would like to publish some info (like calendaring information 
via iCal) using webdav. This would mean a more flexible store implementation, 
and an API to add a store or a whole namespace on the fly.

In general, I think slide needs a makeover. It seems very hard to maintain and 
to use. How about a major refactoring of the authentication / storage / locking 
/ services components for version 3? I think they should be more separated and 
transparent, so that some layers can be skipped for applications that don't 
need them and so that programming in one layer becomes easier (e.g. we don't 
have to worry about locking anymore in the authentication layer). Right now, I 
see a lot of checkCredentials() and checkLocks() all over the place, along with 
many instances where SlideTokenWrappers are needed to either disable or enable 
locking or transaction management in some cases for some obscure reason(s).

Well, enough said for today, back to work! :D



Best regards,

Max Pfingsthorn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-------------------------------------------------------------
[EMAIL PROTECTED] / www.hippo.nl
--------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to