On Sat, Mar 14, 2009 at 8:57 AM, Edward K. Ream <[email protected]> wrote:
>
> 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.

<snarky as hell>
=  "a bit of sucking up to potential users"
</snarky>

> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to