Hi Raphael, While the points you raised are valid, I don't see anything that disqualifies this PLIP. More below.
Your points will certainly be considered for possible improvements after the PLIP is merged. In fact, some of them are already on my TODO. On Feb 18, 2008 5:09 AM, Raphael Ritz <[EMAIL PROTECTED]> wrote: > Hi, > > 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? > Examples: > > (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 > caption) That wasn't a stated goal of this PLIP. > (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. 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 non-folderish. Another issue is, when you upload a file to a 'smart folder', where should this file end up? > (iii) Extensibility: all marshallers don't seem to delegate the > serialization > 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. I don't see how your comment qualifies here though, as we don't ship Plone with any of those different kinds of fields. Moreover, my view (and certainly Alex's) on Working out-of-the-box WebDAV 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, and it's a great improvement over what we had before. 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. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team