Re: Re (2): Basic resource lifecycle: a proposal for "mutable versions"

   From: Edgar@EdgarSchwarz.de

   I'm very confused. Either you misunderstood something
   or you must explain it in more detail because I don't understand the
   connections between my post and most of your reply. Could you check
   whether there are any typos in your use of "ismutable" and "immutable" ?

Yes, I was thinking "immutable", but sometimes wrote "ismutable".
Sorry about that!  (Don't you hate it when people post things without
proofreading them? :-)

   > Edgar's proposal is basically to keep the current "mutable version"
   > semantics, but to require that once "ismutable" is set to "true",
   > it cannot be set back to "false".

   I would still say it's more but only if you exchange "true" and "false".

Yes, or exchange "ismutable" with "immutable".

   > mutable versions.  I believe that any sensible server will refuse
   > to let you set the "immutable" flag on any version with a human
   > meaningful name, since over time, this would result in the limited
   > number of human meaningful names being "used up" by immutable
   > version URL's.

   I don't understand. I don't want to make a "human meaningful name"
   immutable. I just want to make a version immutable.  I didn't want
   to say anything about the topic of meaningful names.  That's
   another matter.

But the people that have been lobbying for mutable versions and "reuse
of version URL's" (Mark and Lisa) want them to have human meaningful
names.  So a solution needs to deal with both issues.

   Why do you think my proposal would use up version URL's ?

If the folks that want to support mutable versions will want them
to have human meaningful names, then if those mutable versions
with human meaningful names are made immutable, then that human
meaningful name can never be used for anything else.  This is
how version URL's would use up human meaningful names over time (if 
a server let you make a mutable version immutable).

   Is this different from when all versions are "immutable" like when you
   don't allow mutable versions ?

Nobody who is supporting immutable versions has asked or expected them
to have human meaningful names.  To the contrary, I believe everyone
that supports immutable versions agrees that you have to add some kind
of GUID'ish string to the name, to avoid using up "meaningful" names.

   > The key point here is that a "stable name" is incompatible with a
   > "human meaningful name", so any attempt to unify "resources with
   > stable names" and "resources with human meaningful names" will
   > never succeed.

   I didn't think I was talking about what you seem to understand,
   please elaborate.

Does the above clarify my point?  (Typing "ismutable" when I meant
"immutable" couldn't have helped much in making my point
understandable :-).

   > So it is unlikely that anybody was ever going to support the
   > "ismutable" transition from "false" to "true" anyway.

   Fine with me. That's forbidden.

Replace that with "It is unlikely that anybody was ever going to
support the "immutable" transition from "false" to "true" anyway.

(And the reason was that those supporting mutable versions want
to give them human meaningful names, so if the mutable version
became immutable, that human meaningful name would be permanently
allocated to that version.

   BTW, my goal was to add limited mutability to core versioning while
   keeping the stability of versions which is the key concept for
   baselines and reproducability.

We already had that ... what we didn't have was interoperability
between clients that required mutable version functionality
and servers that would only be providing immutable versions,
or between clients that required immutable versioning functionality
and servers that would only be providing mutable versions.

But the "variant" proposal does give us that, since it uses
existing mutable behavior (version-controlled resources) to
provide the functionality needed for "mutable versions".

Cheers,
Geoff

Received on Sunday, 7 January 2001 22:14:01 UTC