Sidnei da Silva wrote:
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 <[EMAIL PROTECTED]> 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
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,
Framework-Team mailing list