On Mar 13, 9:22 am, "Edward K. Ream" <[email protected]> wrote:
> > I can't help feeling, despite all the work and all the proofs to the
> > contrary, that someday, somehow, sentinels are going to go away. It will
> > be the result of a major expansion of point of view. Something like c.db
> > or c.zodb.
>
> Let's imagine the impossible for awhile.
This has been a fun exercise, but yesterday I got the unpleasant
feeling that I was trying to solve the wrong problem.
One of the advantages of thought experiments is that they are easily
performed, and easily abandoned. I think that we are likely to have
to abandon yesterdays speculation. It's not a total loss. We have
stirred our created juices, examined some interesting and fertile
ideas, and, as I will now discuss, created some new distinctions.
Let's ask the question: why do we want to eliminate sentinels? As I
see it, there are at least two fundamentally different answers, based
on a new distinction. Let us say someone is a **Leo outsider** if
that person does not use Leo. Leo outsiders:
- have little or no tolerance for sentinels.
- will not be willing to install Leo, or zodb, or Leo-related
extensions to bzr.
This eliminates all the sources of "invention" we discussed yesterday.
For example, "bzr magic" is not available.
For Leo's users, **Leo insiders**, the answer is different. We are
quite willing to accommodate Leo in various ways, but we would still
like to avoid sentinels in various situations, among which are, for
examples, code reviews with Leo outsiders. They don't want to be
"embarrassed" by Leo sentinels.
There is another distinction that occurred to me yesterday, and it
highlights, I think, the scope and nature of the problem to be
solved. Let us imagine that two people, Alice and Bob, are creating
code with Leo and sharing that code with bzr. Alice and Bob could Leo
developers. An interesting question arises. Is there a way for Alice
and Bob to use @shadow to create one of the files on their shared bzr
repository? In other words, the question is:
What would it mean to say that a workflow was *...@shadow-
friendly**?
In other words, we are trying to understand (or create) the
distinction, @shadow-friendly.
At present, as Ville pointed out in an earlier thread, it is difficult
to make @shadow work in a bzr environment. The problem is simply
stated. Bob will not see any structural changes that Alice makes, and
vice versa. We have a "dueling structures" situation. Alice sees the
structures she creates, but Bob does not. Bob sees the structures he
creates, but Alice does not.
For Leo *insiders*, it is just barely conceivable to image some kind
of magic mechanism (not involving sentinels), that would allow Alice
to recreate the structures that Bob created, and vice versa. But
this would be, apparently, a "hard diff" problem.
The apparent conclusion is that making any shared workflow @shadow-
friendly is going to difficult in some way. Either we solve a complex
diff problem, or we restrict Alice's and Bob's workflow so that no
structural changes occur. This does not seem like a sweet spot of
design :-)
The conclusion (always provisional) is that @shadow is not well suited
to collaboration, and that @thin should be the basis of any work
shared via bzr. We could then consider some "magic" that would
eliminate sentinels for Leo *insiders*, but the payoff isn't all that
big. My own sense is that sentinels are, *by far*, the simplest thing
that could possibly work for Leo insiders.
For private work, of course, @shadow remains an excellent choice.
For code reviews, a Leo insider could temporarily convert @thin files
to @shadow files.
I hope you can now see why I said at the beginning that yesterday's
invention seems to have been solving the wrong problem. Indeed, the
desire to eliminate sentinels seems to me in retrospect a bit of
sucking up to Leo outsiders on my part. The combination of @auto,
@shadow and @thin allows Leo to work in any permutation or combination
of environments, and really nothing drastic needs to be done. In
other words, sentinels are not a big problem for Leo, and making them
go away "by magic" either isn't possible (when dealing with Leo
outsiders) or isn't all that important (when dealing with Leo
insiders).
Anyway, that's the way I see things this morning :-) All comments
welcome.
Edward
P.S. There seems to be very little to do to prepare for the Zope
sprint:
- Fix the whitespace problems in @auto and @shadow by stripping blank
lines by default.
- Fix several annoying qt gui problems.
EKR
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
