On Tuesday, Jul 29, 2003, at 17:28 Europe/Rome, Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
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 never found such a case (yet, at least).
Environmental constraint might be symmetrical themselves, but it doesn't necessarely imply that a solution forced by those constraints turns out symmetrical. By expecting so, you might rule out possible solutions to your problem space.
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.
I agree. But this is another concern and not something that we can enforce at framework-design time.
It would be extremely cool, though. :-)
if we give them pieces, people will find out very cool ways of using this stuff, I'm positive about it.
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.
but DAV clients suck because DAV servers suck and are mostly providing an remote file system. change things on the server side and, hopefully, gears wills start moving again in the DAV world.
why not?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.
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.
Yes, you are right.
=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: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.
<map:pipeline dav="on">
And you're definitely right here: I was way too much infected by the DAV syndrome.
Uh, didn't expect you to capitolate that soon ;-) great.
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.
happy to see you agreeing.
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*).
eheh, yep, I knew you would have got it right away.
this is *exactly* why cocoon shouldn't focus on DAV but keep things open. I'm pretty sure we might found out patterns using DAV that could be applied to the entire SOAP/WSDL/UDDI/BPEL4WS stack, just like working on publishing lead patterns that could be applied to webapps as well.
I rarely see a backend and a frontend needing to be kept in synch with sitemap description more than you would do if you hadI 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*.
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.
Pfff, that's nothing compared to what blocks can do for you. I think that I'll spend some time getting you into them today (Gianugo and I will meet IRL to discuss these things)
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 personally think that in a few years people will find it impossible to consider doing anything without using both sitemap and flow (like today is inconcievable doing anything withotu a sitemap), but I agree that today is a little early for that.
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.
cool.
2) pipeline dynamism should be avoided at all costs (otherwise the entire caching design can be thrown down the drain)
Makes sense.
great.
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?
will do IRL and then report back the results of the discussion for the list to continue the design.
-- Stefano.
