[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Webdav + Zope
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-03-19 7:39:51
[Download RAW message or body]

Hi Paul,

On Tuesday, 19th March 2002, Paul Everitt <paul@zope.com> wrote:
>First, I'm extremely pleased to hear about KDE 3's DAV support.  I'm a
>KDE user and am eagerly awaiting the final release, where I'll do my
>upgrade and give it a try.  (In fact, I have a separate computer here
>where I can try to test it out before I go to Zurich tomorrow.)

Great. It's only really getting user testing now, which is of course revealing 
the few rough patches :) In the end it was only about 500 lines of code 
thanks to KDE's design, so it should be easy to maintain and extend.

>Regarding DAV and Zope, my experience with nearly every conceivable DAV
>client has shown me that there is usually more that needs to be done to
>really leverage the integration.  If done, it would make Zope an almost
>invisible storage for KDE data, but in ways more powerful than a file
>system.
>
>Here are some of the things that I'd like to know more about.  I'd like
>to emphasize that I'm not lobbying for you to do more free work, I'm
>just trying to get feedback on what these items would mean in the world
>of kio:

As a preface to my answers, integration is somewhat hampered by the user 
interface capabilities of kio.  I hope to get around this with a konqueror 
plugin (a kpart). At the moment I don't have a time frame for this however. 

KDE is also looking at the kmimetype plugin system. KDE guys: is a provision 
being made for per-slave extended capability plugins? or is kparts all I need 
for the following?

>1) Edit source.  Since Zope is a dynamic system, the output you get from
>a GET isn't the source version of the content.  Zope provides a
>workaround where you setup a separate server port for which GET returns
>the source version.
>
>However, a user shouldn't have to be aware of a "source port" and a 
>server administrator shouldn't have to set it up either.  You should be 
>able to just look at something and click on "Edit Source" in a menu 
>somewhere.  The DAV spec anticipates this, saying that servers can 
>return a src property telling clients where to go for the source 
>version.  Unfortunately, no clients support it.
>
>Explaining the whole source port thing to people is just a huge annoyance.

Yes... the slave is aware of this and sends detected script locations to the 
kde app. A kpart is needed for konqueror to be aware in the UI.

>2) Mime type.  Zope is a rich object system, where you can have
>different kinds of "files", such as new items, expense reports, etc.
>Unfortunately, nearly no DAV clients support any possible way, other
>than file extension, to create a "news item" file.  In fact, some don't
>even send a mime type with the PUT.

I wasn't really aware of this. Where in the UI would you envisage the person 
specifying the mimetype?  I have just checked and we don't send the mimetype 
at the moment... in fact it's unclear to me if kio supports this...?

Again a kpart or custom app could achieve this.

>3) Auto complete.  With PROPFIND support, you can tab-complete the URLs
>when navigating a Zope/DAV folder.

This is already done thanks to a bonus from kio :)

>4) Lock/unlock.  It should be simple to set/remove the lock on a Zope
>resource.  As we start do implement more versioning in Zope, there will
>need to be more operations (checkout/checkin/revert/etc.), as well as
>displaying the versioning status.

Again, done but requires a kpart or custom app support.

>5) Kate XML.  This one might be pretty big.  Kate allegedly has XML
>support in KDE 3.  Thus it is possible that Zope page templates can be
>wonderfully edited directly.

Absolutely. I was pleasantly surprised when I first put Kate + kio + webdav 
together.

>Here are some nice-to-haves...
>
>1) Sync.  I've wanted this for a while -- the ability to do a visual,
>rsync-style application between the local filesystem and Zope (or two
>Zopes).  If the kio slave doesn't directly support it, once DAV is a
>kio-slave, perhaps other KDE file sync apps might work.

Sync as in versioning, like cvs? I don't quite understand the visual part of 
it. A dedicated kde file sync app should do the trick though, or a separate 
konqueror kpart, it sounds like you want to do this between different 
ioslaves.

>2) Undo.  This one should make a lot of sense -- a Zope undo from the
>application that you are using.

Is this a Zope extension? where would I find relevant Zope+dav docs?

>3) Rich presentation.  There is probably a way to make the non-file
>information in Zope, such as security settings and properties, viewable
>and settable in KDE.  Any ideas, without writing a dedicated app?

Again, a job for the kpart.

>4) Scripting from Python.  Some of the items above could be implemented
>outside of the kio slave.  Obviously I'd like to program in Python.  How
>hard is it to extend or script a kio slave?

I think this might be achieved through Python+DCOP bindings. Python+KDE 
bindings would be even better though, I heard something a while back 
indicating they would be forthcoming.

>Again, I'm just curious for information on how these ideas would
>interact with the kio slave.  I'm certainly not complaining considering
>all that you've already done.  Thanks for listening!
>
>--Paul

Thanks for your comments, much appreciated.

Cheers,

Hamish.
[prev in list] [next in list] [prev in thread] [next in thread]