cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Fooling around with cocoon davmap
Date Sun, 02 Nov 2003 09:51:47 GMT

On Sunday, Nov 2, 2003, at 01:26 Europe/Rome, Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
>>> Unico Hommes wrote:
>>>
>>>> Should we strive for strict compatibility in the short term?
>>>
>>>
>>> IMO, yes. We are now building a foundation for Cocoon to be a viable 
>>> DAV server, and this should include finding all the possible 
>>> shortcomings and solve them now instead than later, when we will 
>>> start polishing things up. There's always room for hacks, but I'd 
>>> rather leave them to a later point: now we're more in a proof of 
>>> concept phase, after which I expect some serious design to happen, 
>>> possibly even on Cocoon core.
>>>
>>> WDYT?
>> I think that if I keep hitting rubber walls on merlino build all 
>> sorts of webdav servers and clients, I will end up implementing 
>> DeltaV directly into davmap instead of crying down in tears!!! grrr
>
> Welcome to the interoperability nightmare. :-)

Thanks :-)

> Actually, I think that the DeltaV stuff is not that important as of 
> now: since there are no DeltaV-aware clients apart from cadaver, I 
> wouldn't worry too much: what we need is transparent versioning, that 
> would be more than enough.

Hmmm, not really. For the frontend, transparent versioning is cool, but 
for the backend, well, it's not. I must be able to instruct the 
repository to roll back... for example, in case doco committers make a 
mistake and approuve a patch via email that wasn't supposed to get 
there.

>> don't you hate with you think you have all pieces of the puzzle 
>> finally on the table, but then you figure one that you miss one 
>> more... and then one more... and so on... it's driving me nuts.
>
> Why so? The most important missing piece actually is a client for 
> infrastructure to restore sites from previous versions: this shouldn't 
> be too hard to do after all.

nah, that's easy. I'll have the rsync feeding cronned script from 
minotaur commit on a local CVS first. So that infrastructure can do a 
easy "site checkout" if something goes wrong. [pure paranoia, IMO, 
given that both sites and CVS are on the same machine but what do I 
know]

> Keep in mind that, even with DeltaV, you wouldn't have been that much 
> closer: as of today, there are just no clients available, so we'll 
> need to build our own anyways.

uh? I thought the Slide WebDAV client library supported DeltaV, isn't 
the case? [if so, sorry, but I'm hooking to the subversion native 
libraries]

> Unless (wild thought) we manage to have davmap working on arbitrary 
> sources: if so, we could use the CVSSource as the "filesystem" 
> backend, giving us transparent versioning for free. We're not that far 
> away, actually...

hmmm, on second thought, what if we throw webdav down the drain and 
drive CVS directly from the backend with the CVSSource? the 
architecture is much weaker (there is no more clear separation between 
backend and repository) but the implementation sounds easier.

And having CVS as a repository is still better (in the 
infrastructure@'s eyes) than having cocoons all over the place.

comments?

--
Stefano.


Mime
View raw message