Edgar`s comments to 12.1

Hi,
I finally managed to get some time (refusing to go for a walk with the rest of the family :-)
to give some last comments to 12.1. Because I didn't have much time lately I couldn't make
a full review of even my pet themes but will again present a scenario I would like to able
to realize with WebDAV and DELTA-V. 
I understand that even if some things I would like to do won't be possible with DELTA-V
nevertheless it will be a fine foundation to build "my goodies" on. 

Thanks Geoff, for posting the model. I couldn't view it at work (Too many ActiveX stuff which
probably was blocked by our company firewall. The navigation frame to the left didn't work)
but did so at home.

I agree to the the sentiment somebody raised that DELTA-V is rather complex. So I also
would like to see a companion document (E.g. the FAQ mentioned in a recent posting).
Variants e.g. would need an entry there in the context of solving the "meaningful URL"
scenario discussed in the mailing list.

Now my model and scenario for an application. I tried to make the example it as small as possible but still
meaningful enough.
The complete application has several variants. So a variant consists of of common and special components, 
where a component is defined by the members (not shown below) of a collection.
Now let's have a look at the version history world and the newest version of the component.
Remember that the hierarchy of the version histories doesn't imply that a baseline (what I would have called
just a version)  of a collection belongs to a baseline of a parent collection. This relation could probably be
realized by a subbaseline. For components I added a version number.
app#1 
	doc
		common#1
		sun#1
		win#1
	gui
		sun#1
		win#1
	code
		common#1
		sun#1
		win#1
	sun#1
	win#1
	
For the complete project with all components I say:
	 app#1 = app/sun#1,app/win#1
	 
The variants would be defined like this:
	app/win#1 = app/doc/common#1,app/doc/win#1,app/gui/win#1,app/code/common#1,app/code/win#1
	app/sun#1 = app/doc/common#1,app/doc/sun#1,app/gui/sun#1,app/code/common#1,app/code/sun#1
	
Now somebody wants to work on the win part of the stuff (needs more bugfixes than SUN I guess :-)
He is creating a workspace containing the stuff he needs (Mapping collections to the workspace according to
developers taste. This feature avoids lenghty discussions on code structuring :-)
winbugws
	doc
		common (app/doc/common)
		win (app/doc/win)
	gui (app/gui/win)
	code
		common (app/code/common)
		win (app/code/win)
	app (app/win)
Suppose he changes some stuff in the win gui. This will mean there is a app/gui/win#2.
Now he would create an new win baseline:
	app/win#2 = app/doc/common#1,app/doc/win#1,app/gui/win#2,app/code/common#1,app/code/win#1
If somebody creates a new baseline of the complete project later only the win version number needs updating:
	app#2 = app/sun#1,app/win#2
	
That describes  in short what I built with RCS and Unix scripts. The implementation isn't very efficient and
restricted to one site. But the concept worked for a couple of thousand files, some dozens of developers and a lot of
variants over a couple of years.
I guess I can realize this concept with DELTA-V following the way Geoff described in an earlier reply. Geoff, perhaps
you could add this scenario and it's tranlation to DELTA-V to the FAQ document ? Just a question. Sorry, that I want
you to do additional work but you are the person who could do it best I think.
	
Now finally some comments to the draft:
As I understand it at the moment subbaselines are very important to port my model to DELTA-V.  So I'm not happy
to read  in 10.2.2: "A server that supports the baseline option MAY choose to not support the DAV:subbaseline-set
property". I would like to drop this sentence or at least change "MAY choose to not support" to "SHOULD support".
So the question is, do others also think my model makes sense and should be available to clients if the server supports
baselines ? Or are subbaselines a heavy burden on servers or server writers, so they want to avoid them ?

1.3.1 Configuration
"Note that a collection (which is a single resource) is very different from a configuration (which is a set of resources)"
In "Collection Resource" you state that "A collection ... consists of ..., a set of named bindings ... . Note that a binding
is not a resource ...". Nevertheless this set of binding logically is equivalent to a set of resources. So I'm not sure I
see the big difference between collection and configuration.

10 Baseline Option
"... A Configuration that contains a large number of resources can consume a large amount of space. This can make
it prohibitively expensive to remember the state of an existing configuration by creating a copy of it's root collection.
A 'Baseline' is ..."
It doesn't sound good to me to create a new term based on assuming a dumb implementation (Naively creating a copy).
Why not just use a "version of a collection" ? Efficient implementation is the task of the implementation, not the
protocol.

So my main problem left with the latest draft is that I see two similar concepts: Configurations and Baselines to
capture their state versus Version-Controlled-Collections and their versions. I admit that there are differences
but nevertheless my feeling is that these two concepts should be merged somehow.
I fear they will confuse future users of DELTA-V. So at least I would like to have the rationale to make them different
made clear in the aforementioned FAQ.
Another alternative perhaps would be 12. You describe some reasons for version controlled collections (Mentioning
activities, workspaces and merging. So it seems there is some entanglement between options. Which probably is
unavoidable I fear). Could you also mention the difference to configurations and baselines here ? 

Cheers, Edgar  
	
-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Sunday, 28 January 2001 18:09:49 UTC