[Framework-Team] Re: comments on plip187: WebDAV
raphael.ritz at incf.org
Mon Feb 18 14:27:05 UTC 2008
Sidnei da Silva wrote:
> Hi Raphael,
first of all thanks for your prompt reply!
> While the points you raised are valid, I don't see anything that
> disqualifies this PLIP. More below.
I'm also going to comment inline below ...
> Your points will certainly be considered for possible improvements
> after the PLIP is merged. In fact, some of them are already on my
> On Feb 18, 2008 5:09 AM, Raphael Ritz <raphael.ritz at incf.org> wrote:
>> here my current take on this PLIP:
>> tested on Linux/Ubuntu 7.10 with Nautilus and Cadaver as WebDAV clients.
>> First, my overall impression: I'm somewhat at a loss here as I don't know
>> what to expect and therefore I don't know what to recommend. :-(
>> While all changes introduced are worthwhile improvements (and could go into
>> Plone core as far as I can see) I'm hesitant calling this
>> Working Out-of-the-box WebDAV
>> I think my problem is: what does "working WebDAV" mean?
>> (i) Binary fields: when editing a News Item via webdav I don't see how
>> I could manage the image that can be included with an item (nor its
> That wasn't a stated goal of this PLIP.
OK, fair enough.
>> (ii) Folders: When copying over (downloading) the default news folder I
>> get a series of error messages from the aggregator topic's criteria
>> (not too surprising) but no news items at all (and of course I've created
>> a few in there before).
>> More generally, folderish items seem to be problematic still.
> The 'news folder' is not a folder, is a 'smart folder'. It does
> (should?) not contain files, but basically presents a search result.
> As such, it is hard to decide what should happen there, and I'm open
> for suggestions.
No, it's a bit trickier than that: In current Plone 3 the news folder
is an ATBTreeFolder which contains a topic as default view.
It is perfectly fine (and actually supported through the default
Plone UI) to add news items to this folder.
The problem I was having is that when trying to download the
*folder* I didn't get the news items contained in there probably
because of the errors triggered by the contained topic.
See what mean now?
> We could either:
> - Display the 'contents' of a 'smart folder' and allow for
> downloading them. The problem might be that since they are not
> directly contained inside that 'smart folder', maybe some WebDAV
> clients will complain that the URLs for those items are not 'contained
> in' the parent.
> - Serialize the criteria for the 'smart folder', and display it as
that seems to make most sense to me at the moment
> Another issue is, when you upload a file to a 'smart folder', where
> should this file end up?
I'm not sure we should even try this.
>> (iii) Extensibility: all marshallers don't seem to delegate the
>> of field values to the fields but rather apply some heuristics to the value.
>> While the current implementations work for field types shipped with AT it
>> is limiting when it comes to supporting custom field/data types.
>> (e.g., my Record- and RecordsField (dict and list of dict types) are not
>> treated correctly neither can I easily hook in my own serializations.
>> I guess other complex field types like the ArrayField, the DataGridField,
>> the CompoundField, etc. might have the same problem.)
> I did not design the marshalling layer on AT, though I contributed
> many improvements to it. It is completely possible to create a
> marshaller that delegates to each field.
That's kind of the point I was trying to make: it would
certainly be possible (and not that hard even).
> I don't see how your comment qualifies here though, as we don't ship
> Plone with any of those different kinds of fields.
While you are right in the strict sense I do propose
to take a broader look at this. And from my perspective
things could be better here. People often don't draw the
fine line between Plone the product (as it comes OOTB)
and Plone the platform/framework/whatever you call it.
> Moreover, my view (and certainly Alex's) on Working out-of-the-box
I guess this is what I'm most worried about: Calling this
Working out-of-the-box WebDAV
Maybe I'm the only one who has these "strange" expectations
but for issues like the ones mentioned above I feel uncomfortable
with advertising it as such.
> is: you drag a file in, and you get a file (preferably the same
> file) out. The previous status-quo, which *tried* to serialize each
> field individually could be interesting to geeky types who know what
> they are doing, but is totally useless as there are no known editors
> (other than text editors) that could edit those files.
>> Recommendation: as I think any improvements on the WebDAV side are worth
>> it I'm generally positive but I would be hesitant advertising it too boldly
>> (WebDAV is maybe just too broken in general?).
> It is certainly not too broken,
OK, maybe my expectations are somewhat broken then.
> and it's a great improvement over what
> we had before.
Didn't I say so as well ;-)
> We can incrementally improve on what we have on this
> PLIP. Going from 100% broken to 100% working is not a trivial task
> that can be achieved in one release cycle.
Absolutely, and again I'm mostly worried about raising
too high expectations where we aren't fully up to (yet)
in order to avoid unnecessary frustration by those who
might expect too much then.
Guess I should be +1 then nevertheless,
More information about the Framework-Team