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

List:       kfm-devel
Subject:    Re: Webdav + Zope
From:       Paul Everitt <paul () zope ! com>
Date:       2002-03-19 15:52:56
[Download RAW message or body]

Hamish Rodda wrote:
> 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.

That's good to hear.  I just read in today's KDE Kernel Cousin that the 
address book is getting an abstraction on the backend as well, allowing 
storage of contacts in SQL as well as LDAP.

>>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. 

Yes, this UI issue is the part where I also don't understand the options.

Considering the runtime, dynamic nature of the interaction, XML happens 
to be a reasonably good way for the server to tell the client about its 
capabilities.  The presentation of the XML can be in a native fashion 
(KDE/Qt widgets) or CSS/XSLT.  The issue becomes taking actions and 
manipulating state.

> 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.

Ideally, in KWord I could do "Edit Source" if the server tells the 
client there is a src available in the properties.

>>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...?

Right-click, New->[sequence of builtin types, sequence of extended types]

This is the behavior under Windows.

> 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 :)

Great!


>>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.

I don't think that it should, since there are HTTP verbs that specify 
this.  It is simply a question of how (or whether) to display it).

>>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.

Any idea if Kate can handle XML namespaces on attributes, such as:

   <p tal:content="here/title">Some text</p>

>>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.

Not really like versioning.  Rather, a two-paned view that compares 
local to remote, then shows the add/change/delete differences in 
resources.  Similar to cadaver, which has a Gnome frontend.

>>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?

Zope has an undo capability that can be driven through a URL scheme.  If 
KDE was extensible, we would likely wire this in via custom DAV 
properties, to expose the undo information.

>>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.

Right.  Can a kpart be written in Python?

>>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.

Yep, a beta just came out supporting KDE 3.

Thanks for the discussion!

--Paul

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