RE: Working Resource Issues ...

The challenge of writing a protocol is not to make it work
for a wide variety of servers, and many of the servers today
require workspace functionality.  Therefore ignoring the requirements
for compatibility with servers that support workspaces is
not an effective path forward.

Cheers,
Geoff

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]

> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of 
> Edgar@EdgarSchwarz.de
> johnhall@evergo.net wrote:
> > I've also mentioned that I'm concerned with 3rd party 
> emulation.  The 
> > 3rd party has a 'working version', and that is exactly how they 
> > implemented the concept.

The current state of things is far more complex than what I have asked
for.  It is far more complex than some existing clients have asked for.
All I've really asked for is a CHECKOUT that means checkout, a working
resource that isn't visible to the world, and a CHECKIN that means
checkin.

There is no need to introduce the additional complexity and operations
of WORKSPACE, UPDATE, and MERGE, or to change the commonly understood
implications of the words 'checkin' and 'checkout'.  

The path of execution a client goes through under my proposal is almost
completely identical to the check-out-in-place and let the world see
your stuff thread.  The workspace system isn't.

In common terminology we have an excellent word for 'frozen'.  CHECKIN.


> 
> > 4.1.3  DAV:checkout-invisible
> > Normally, edits made on a resource while checked out are visible to 
> > other users.  If checkout-invisible is specified, however, 
> other users 
> > will only see the last checked-in version.  A client is 
> encouraged to 
> > see this feature as "lite" version of WORKING-RESOURCE which leaves 
> > the VCR in the checked-out state.

> You say you don't need UPDATE so here I say 
> that I don't need this invisible thing.

Since I don't begrudge you your WORKSPACE, you shouldn't begrudge me
this 'invisible thing'. 

The problem is that you want to compel me to either not deliver my
functionality to my users, or to implment workspaces and bring in a load
of other things / issues / complexity / problems.

If you HAVE implemented a workspace feature, then you have already
implemented 99% of this 'invisible thing'.  The reverse is far from
true.


> But this makes things difficult for the DAUs 

Don't worry about them, they'll be using my clients and not bothering
with WORKSPACE at all.

> So if you delete 
> your working resource the versions history also can go down 
> the closet. 

My working resources do not have their own independent version history,
and I'm not sure you can really take that from the spec on WORKSPACE
either.

> We have thousands of source files which we have to 
> freeze in baselines. 

Then don't use my server, I don't support baselines.  And I've been
involved in some very large systems projects with thousands of source
files and millions of lines of code.  We got by without baselines and
code forking.  But my server isn't targeted to source code control, the
idea of versioning has wider application than that.

> Hey, the changes I 
> made today are wrong. Let's go back to and earlier version 
> (Perhaps not the last one). That's what UPDATE is for.

1) that is what "DELETE version" is for.
2) or CHECKOUT, GET old.version, FILE SAVEAS, CHECKIN if you'd prefer. 

> So at last my question: Couldn't agreee to implement UPDATE ? 

NO.

> Not 
> that complex and uncommon I guess (co -r <filename>) Perhaps 
> we then could stop some threads which threaten to make the 
> spec more complex.

It has already been made complex.  I'm trying to add something to make
the complexity optional and ignorable.

Received on Thursday, 21 June 2001 18:20:04 UTC