RE: Working Resource Issues ...

I'm not asking you to ignore the needs of workspace functionality.  

Indeed, I moved my focus to make the seperation easier to understand.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Thursday, June 21, 2001 3:26 PM
> To: ietf-dav-versioning@w3.org
> Subject: 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 19:14:54 UTC