cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Tue, 06 Nov 2001 12:41:37 GMT


Stefano Mazzocchi a écrit :
> 
> Per Kreipke wrote:
> >
> > > > > Again, I think WebDAV access through Cocoon is more than worth the
> > > > > effort.
> > > >
> > > > Definitely worth having, not clear how :-)
> > >
> > > Uh, what a thread :)
> > >
> > > Ok, let's try to summarize a little.
> > >
> > > This is what I believe is a good chain for publishing:
> > >
> > >  user agent <- publishing <- store <- CMS <- edit agent
> >
> > I agree with Gianugo that the CMS should hide the store:
> >
> > user agent <- publishing <- CMS <- edit agent
> >                               |
> >                             store
> 
> Yes, good point. This is definately easier to componentize.
> 
> > > which is a native XML DB. IMO, it lacks a few features to turn it into
> > > such a storage system (most notably, versioning, locking and a few other
> > > things that things like CVS has), but it's a great place to start and a
> > > great way for the publishing system to have access to the content (thru
> > > XQL or the like).
> >
> > One thing I'm not thrilled about with dbXML is that it's document centric
> > [my opinion may be out of date, I'm not sure], it's hard to query across XML
> > documents.
> 
> Look: XIndice is not dbXML moved to Apache, it's a new project "seeded"
> with the current dbXML implementation so that users can take a look at
> it and shape the further direction of the project.
> 
> So, I totally agree that document-centric view sucks. IMO, a native XML
> DB should be seen as ONE BIG XML DOCUMENT and then you have an XQL
> frontend to query information and a WebDAV mapping backend so that
> people can know if an element should be considered part of a directory
> or part of a file.
> 
> (this can easily be achieved with some namespaces attribute on an
> element that states that it is a root element for a document)
> 
> But this is a talk for the XIndice mail list (when it will show up).
> 
> > >  user agent <-(http)- cocoon <-(xql)- xindice <-(?)- ? <-(webdav)-
?
> > > which leaves three big question marks.
> > > The unknown contract will probably be filled by the xindice guys (XMLDB
> > > API being the probably candidate, but maybe a JSR would add that
> > > functionality into JDBC4, I don't know at this point, but I'm confident
> > > that something will come out as soon as the xindice people (with us)
> > > tackle the problem in detail).
> >
> > Ok, so given that we eventually define all the contracts, why do we need to
> > choose the implementations? I think that, in the J2EE vein, being able to
> > choose my own implementation for
> > 'standard services' is a great one.
> >
> > Isn't it ok to define the missing contract but leave the implementations as
> > '?'.
> 
> Yep, it is. But around here, it's good to provide both so that you
> actually have something that works and don't have to way years for the
> JCP to approuve your proposal, get the spec out and then buy WebSphere
> 15.0 that implements it.  :)
> 
> > >  1) CMS because Cocoon shouldn't implement CMS stuff but should simply
> > > "use it". Things like user management, locking, revisioning, metadata,
> > > scheduling and all that should be a layer built around the storage. The
> > > contract between CMS and cocoon being some API or some avalon behavioral
> > > services.
> >
> > Great!
> >
> > > At the same time, content editors don't give a shit about "where"
> > > resources are located and I disagree vehemently with Gianugo when he
> > > says that you have to give them the harddisk methaphor otherwise they
> > > are screwed.
> > >
> > > Well, they would be anyway: in fact, when they approach an editing
> > > system, they don't ask the question "where", but "what". The translation
> > > between "what content to modify" and "where to save it", mixes concerns.
> >
> > Based on some exerience, I agree with you Stefano. One example, newspaper
> > editors deal with departments, 'beats', teams, campaigns, what have you,
> > many of which cross over. Their organization certainly doesn't have to be
> > hierarchical. And newspaper writers are very accustomed to filing stories
> > from far away without a 'desktop' metaphor at all. In fact, they're so
> > _extremely_ time sensitive (down to beating other competing outlets by
> > seconds with a news story), they rarely use cumbersome, slow, generic word
> > processors, they use highly customized apps.
> 
> Bingo!! exactly. I'm trying to cover exactly those use cases where
> people what to focus on their job (writing content) rather than figuring
> out where to save it in order not to break the system!
> 
> > > How so? A XUL-powered mozilla IDE that integrates skeleton-based
> > > in-place editing capabilities.
> >
> > I don't understand. Why not just say 'XUL for in-place editing'? Why does it
> > have to be mozilla based?
> 
> Good point. :)
> 
> You're right: "xul for in-place editing", then Mozilla is just one of
> the possible implementations.
> 
> Note: XUL is proprietary, but can you say that something is proprietary
> if it's done by an open source project? IE HTML is, in fact, more
> proprietary than XUL from that point of view, even if it's a well known
> standard.

XUL isn't so proprietary : other implementations and tools are coming.
Do you know JXUL (www.jxul.org), a XUL engine written in Java/Swing, and
Cocktail (www.applese.com) that contains a XUL GUI builder ?

> > > So, should webdav be integrated into Cocoon? well, at this point, it's
> > > early to tell and it depends on the shape that the CMS part will take.
> > >
> > > One thing in my mind is for sure: Cocoon shouldn't become a CMS, but
> > > might well adapt the CMS API with the XUL-powered solution and, in that
> > > case, it might require some WebDAV capabilities of some sort.
> >
> > Ah, there it is without any choices about what CMS or editor I have to tie
> > myself to :-)
> 
> Exactly: webdav can allow all usage editing solutions to cohexist.
> Wouldn't this be great?
> 
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message