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.
The clients that are built-in to tools, are another thing which I know
exists. My fault, I didnt make my falvour of client I would like to see
clear! I am looking for a client that integrates directly with
WindowsXXX seemlessly.
What is the 'Gnome/KDE DAV stuff' which you refer to ? Is that the
builtin filesystem stuff in the desktop or is there a specifics client
you are referring to ?
As for more people getting involved, I think there is more than one way
to skin a cat. I think a good windows client would encourage more people
to use the server, and in turn bring more developers.
I agree at the moment the project seems to have few developers, and slow
release/fix cycle.
I guess I am proposing incorporating clients into the project itself to
help ease people into the project, users and developers.
Gregory Block wrote:
Hiya.
Speaking as someone who's done the integration work for his apps, and
now has to support this when used by the content team...
On 12 Sep 2005, at 10:20, Paul Hussein wrote:
It seems to me that groupware, and management of documents in groups
is a fast growing requirement is small and large organisations. The
slide projet has a worthy document repository, but has no client.
Not really fair.
We regularly make use of GoLive CS, Dreamweaver MX, and the
integrated MacOS/X and WinXP clients to access the dav store.
Sure, the WinXP one sucks. No doubt.
The others are all fine, though. Dreamweaver can be a bit funny,
sometimes, and lock files when we don't want them to, but it *does*
all just work.
The two main desktops out there are windows and linux. Windows Web
Folders does not work.
See above. I've got no problems with it. Mind you, I did have to
write a content interceptor for something to do with it.
To be frank, that's where most of my time has gone - content
interceptors for MSIE, metadata extractors for GIF and JPEG data
(creates EXIF: data in the metadata of the file, etc.)...
I did spend some time trying to write a new store format for better
performance, but that's on the back burner for a bit until I have a
look at Nutch's distributed filesystem implementation.
The only client that can be used in windows to any degree of
usability/stability is SRT Webdrive. However this lacks searching
and ACL.
Do you mean ACL editing, or *obeying* ACLs? It obeys acls just fine,
as does every other webdav client. As for editing... well, you've
got a point there. That's outside of the scope of our particular
app, because acls are maintained by the app.
On linux there is DAVFS which is a lil complex but works well to
mount the files.
We've had *nothing* but problems with DavFS. It's a nightmare of an
implementation, not made easier by the Linux dev team's refusal to
incorporate Coda into the kernel.
What we *have* had better luck with is the Gnome/KDE DAV stuff, which
does work well.
One other interesting area is subversion. It seems strange to me
that the subversion team have written their own WebDAV module, when
a perfectly decent webdav module exists within slide.
SVN != DAV. However regrettable we all may feel that WebDAV didn't
become the API of choice for SVN, and for whatever that's worth, the
two will probably always be separate, I guess.
Seems also there is a need to develop a webdav client integrated
into the windows desktop much like netdrive/webdrive to give the
same functionality as the srt groupware product ( http://
www.southrivertech.com/index.php?pg=./products/groupdrive/index ).
SRT's been around for a long time, doing what it's doing now. I
don't see any problem with that. If you feel strongly about it, feel
free to kickstart a davfs project for Windows...
But the availability, or lack thereof, of a commercial or non-
commercial client on Windows hasn't prevented takeup of Slide here.
What prevents takeup is the lack of progress, the continued bugs, the
complexity of setup, the difficulty in replicating the content
backend safely.... All kinds of stuff more directly related to Slide
itself, all of which can be solved by more people getting involved,
and the dev team being more proactive about including patches
provided by people.
F.ex., 2.1 is pretty hosed, IMO. 2.2 is pretty solid, in comparison,
and we're using a CVS checkout of 2.2 because it fixes bugs in 2.1 -
but 2.2 is still an unknown quantity away from release, and there's
no sign of a 2.1 patch release.
What we need isn't developers running off and building clients and
reinventing wheels. What we need is eyeballs and hands, here and
now, working on this code.
As soon as I can clear away some of the cruft from the content
interceptors, and make them follow the non-deprecated API, I'll offer
the project most of the work we've done here - including a new FS
implementation if we do move to the Nutch DistributedFS
implementation to solve our clustering problems.
Sincerely,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
