On Sunday, Nov 2, 2003, at 01:26 Europe/Rome, Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:Unico Hommes wrote: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
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?
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.
