Careful here: I never said that a "symmetrical design is bad" (actually, I love when designs become symmetrical), what is bad is "symmetry-driven design".
The design should be done driven by the constraints where it must operate and it should, at the end, turn out symmetrical, or, at least, it should be possible to find a pleasant visual representation of the concept.
Nice explanation, thanks. But then what when an environmental constraint is simmetry? ;-)
I see that you don't particularily like the "web folders" metaphore,
Again, I never said I didn't like the "web folders" metaphore. I said I didn't like the "web folders" implementation on IE which is buggy as hell. I stated that I love the fact to be able to mount a webdav server as a file system on macosx (and WinXP, Guido says, but I never used XP so I don't know)
OK, then you have to recognize that, usability wise, might be somehow uncomfortable for Joe User to drag "my.xls" and find "my.xml" popping out. It would be extremely cool, though. :-)
I don't see it. Actually /home/blah/news is a directory even if you don't put a trailing slash on it, and you can't have a file and a directory sharing the same name. But this is nitpicking.
My point was: on a file system, you are not precise with a trailing slash, in some cases things don't work properly, on the web this is much less so.
Definitely so. 302 on webdav are a PITA: infact, even with HTTPClient, you have to tweak the apache conf to be able to handle redirects.
If I have a resource like http://blah.com/news/ and I want to edit, I could ask for http://blah.com:8888/news/ http://edit.blah.com/news/ http://blah.com/news/?view="edit";
Well... yes and no: in a shared folders scenario this doesn't apply.
why not?
Because, as you point out later:
I don't have to remind you that fat clients (webfolders and FS mounters included) don't allow you to specify what type of request parameters you want in that webdav request. This forces you to use a special URI space for your webdav folders
So that getting via webdav ?view=edit is out of question.
The real problem is what's Nirvana for each of us: to me it would be just great to have a way of automatically expose a Cocoon pipeline both as an HTTP resource *and* as a DAV (editable) resource. Something like:
<map:pipeline dav="on">
I think this is mod_dav injected nirvana, but I don't see why DAV is so different to treat it in such a special way.
And you're definitely right here: I was way too much infected by the DAV syndrome. You have a strong point, and yes, the future developments should aim to provide new sitemap semantics and components to deal with this new kind of requests, where the border between context and payload (as NKB correctly draws) is blurred.
Having these advanced "xml-rpc" capabilities would men a hell of a lot for Cocoon NG: as one of my bosses pointed out this morning, this is exactly what would be missing to use Cocoon as the perfect EAI tool (yes, I know that you don't give a damn about EAI, but this is a scenario where Cocoon would just *rock*).
I normally prefer the virtual-host approach. something like this
[frontend] <- [repository] <- [backend]
http://blah.com http://edit.blah.com
where frontend and backend are separated (frontend might even be a static representation of the saved content (say, created by a cronned forrest every hour or so).
The above setup removes you from the need from having to be symmetric.
This is yet another approach: a different Cocoon with a different configuration. Feasible, but then again possibly unmaintainable since it requires to keep in sync two different pipeline *logics*.
I rarely see a backend and a frontend needing to be kept in synch with sitemap description more than you would do if you had
host.com/ host.com/edit/
mounted on different subsitemaps.
Yes. My point was that plain HTTP should be the "public" site, and DAV the administration part. But then again, this should be handled differently and kept in sync, so I concur.
Besides, you don't take into account the future where cocoon webapps will be hotdeployed. in that case, it's totally possible to create the two frontend/backend sitemaps XSLT-transforming a common sitemap that includes different metadata at block-creation time.
Sweet. :-) Can't wait for blocks then.
I disagree here. Cocoon is bidirectional *if* flow is used, which is a serious limitation. Actually I've been struck by this lately, on a presentation engine we are building, and I see a possible solution (but it deserves an RT on its own).
You are right. Cocoon is bidirectional if flow is used.
I didn't think about it because, to me, it's like saying "cocoon is useless if the sitemap is not used".
No, I don't think we're there yet. Even though Linotype is a very good proof that flow goes way beyond the traditional form-based webapps, I still think that there should be room for more declarative ("classical"?) approaches using only the beautiful sitemap semantics.
I agree that this should go away: the sitemap should be more friendly to all those request-with-payload, no matter what the payload is (multipart/encoded,webdav,soap,xml-rcp), but a few issues:
1) it should not be DAV-only since DAV is just another xml-over-http. DAV-specific functionality should be in the implementations not in the abstractions.
Definitely: consider me sold.
2) pipeline dynamism should be avoided at all costs (otherwise the entire caching design can be thrown down the drain)
Makes sense.
3) DAV functionality should *not* be composable just like normal request pipelines (meaning that webfolders-like functionality should be a behavior of the composition of components, not an implementation of a particular component). This allows for easy webdavapp creation. At the same time, creating a simple webfolders-like approach should be as easy as composing a few pipeline.
I didn't quite follow here... care to spend a few more words?
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
