ENB: Fixing gnx collisions without a post scan

[Edward K. Ream]

This is an Engineering Notebook post.  Feel free to ignore it unless you have a deep interest in bug #69.

Bob has just reported that the post scan works for him.  That's great, but I would like to eliminate the post scan: it is *almost* never needed and it slows down *every* load of a .leo file.

This post discusses a way around the post scan by adding a new field to gnx's.  I'm dithering about whether to do this: It's a big change to the format of gnx's and it changes Leo's crucial read/write code.  Don't panic: nothing has been decided.

===== Background & terminology

Recall that we say that an invocation of Leo (an instance of g.app) is **based** on the timestamp computed when *that invocation* of Leo starts.

Bob's previous fix guarantees, as much as possible, that no two invocations of Leo are based on the same time stamp.  The post-scan requires this!

The post-pass adjusts the lastIndex ivar of the singleton g.app.nodeIndices (ni) object so that all newly-created gnx's are guaranteed to be unique, regardless of other loaded .leo files in the present invocation of Leo.

===== The idea: one more field in the gnx

Leo's gnx's would change from::

    id.timestamp.n

to::

    id.timestamp.fn.n

where fn is the **file number** for the commander (.leo file) that is creating the gnx.

It is easy for Leo to assign a new file number, say c.file_number, when creating each commander.

===== Why fn solves bug #69 without a post pass

The fn field is unique for each commander, so it guarantees that gnx's created in separate commanders can never collide, even though n starts at 0 for each commander.  It's really as simple as that.

====== Details

We must ensure that we can read and write gnx's properly.

The crucial requirement is that the commander c must be available for all calls to ni.getNewIndex so that c.file_number is available.  Happily, this is so.  In fact, the only "real" calls to ni.getNewIndex are in v.__init__, fc.getLeoOutlineFromClipboard and at.writeNodeToString.  c is available in each case.

v.context is a commander, but context might be None.  In that case, ni.getNewIndex should use fn = 0, which in turn means that "real" commanders should have fn >= 1.

Amusingly, there is also a call to ni.getNewIndex in ni.toString, but it turns out that that call is never used!  Indeed, there used to be lots of calls to ni.toString.  Most of these calls are all gone, although I left them commented out throughout Leo for reference.

Only one call to ni.toString remains, in createSaxVnode::

    v.fileIndex = ni.toString(ni.scanGnx(sax_node.tnx,0))

Evidently, ni.toString is more complex than it needs to be.  Formerly, ni.toString handled all kinds of input, but now it only ever called once, with ni.scanGnx delivering a 3-tuple:  theId,t,n.  So we could eliminate ni.toString entirely, and replace it with ni.tupleToString::

    def tupleToString (self,theId,t,n):
        '''Convert a gnx tuple to its string representation.'''
        return g.toUnicode("%s.%s.%s" % (theId,t,n))

Even with the new gnx's, ni.scanGnx could *still* deliver a 3-tuple theId,t,n, with n having the form "fn.n".  That's why tupleToString must use %s instead of %d to convert n.

===== Risks

1. ni.scanGnx must handle gnx's of the form::

    id.timestamp.fn.n

and deliver (the string) fn.n as the value of n.  This is in *addition* to handling all forms of legacy gnx's. This is *not* a slam dunk.  A very careful set of unit tests will be required to ensure that the new ni.scanGnx handles everything in a bullet-proof manner.

2. I must make *sure* that there are no problems before releasing any code.  The last thing I want are new-style gnx's in .leo files that aren't handled properly.  Getting rid of them (or adding permanent work-around code) would not be pleasant.

BTW, Leo's write logic remain completely unchanged: v.fileIndex is always as string. The write code just writes that string, whatever its format.

===== Conclusions

It's tempting to eliminate the post-pass, but risks must be handled properly.

I am leaning to adding the extra field--I can experiment without changing Leo's core much.  Furthermore, this is an opportunity to retire ni.toString entirely, replacing it with something simpler.

There is plenty of time for further reflection. Your comments, please.

Edward

[Kent Tenney]

You're sure this level of complexity is required ...
timestamped uuids won't work?

> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Wed, Oct 15, 2014 at 6:04 AM, Kent Tenney <kte...@gmail.com> wrote:
> You're sure this level of complexity is required ...
> timestamped uuids won't work?

Yes, uuids would work, but they are not visually acceptable, imo.

BTW, we must ensure that context (commander) is never None in the
vnode ctor: otherwise potential collisions can arise. Happily, Leo's
core always sets the context when creating vnodes.

Edward

[Kent Tenney]

(I'll let go of this soon, I promise)

> not visually acceptable

Who sees them when?
My understanding is that they are only visible when looking
at the xml in a Leo file, am I missing a usage which directly
involves people? My impression is that the xml file hasn't
had people friendliness as a priority.

[Edward K. Ream]

On Wednesday, October 15, 2014 5:57:00 AM UTC-5, Edward K. Ream wrote:

> Evidently, ni.toString is more complex than it needs to be...we could eliminate ni.toString entirely, and replace it with ni.tupleToString::

Without committing myself to eliminating the post pass, I have replaced ni.toString with ni.tupleToString.  I have also generalized ni.scanGnx and added a unit test for same.  All unit tests pass, but much more testing is needed before committing even this much.

Edward

[Terry Brown]

On Wed, 15 Oct 2014 03:57:00 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> This is an Engineering Notebook post. Feel free to ignore it unless
> you have a deep interest in bug #69.
>
> Bob has just reported that the post scan works for him. That's
> great, but I would like to eliminate the post scan: it is *almost*
> never needed and it slows down *every* load of a .leo file.
>
> This post discusses a way around the post scan by adding a new field
> to gnx's. I'm dithering about whether to do this: It's a big change
> to the format of gnx's and it changes Leo's crucial read/write code.
> Don't panic: nothing has been decided.

Good :-)

> ===== Background & terminology
>
> Recall that we say that an invocation of Leo (an instance of g.app)
> is **based** on the timestamp computed when *that invocation* of Leo
> starts.
>
> Bob's previous fix guarantees, as much as possible, that no two
> invocations of Leo are based on the same time stamp. The post-scan
> requires this!

I don't think the post-scan does require Bob's always incrementing
timestamp fix, I think the post-scan is a more general solution which
addresses the ".leo files from other sources" aspect of the duplicated
gnx problem, as well as the "loading the same file twice in one second"
aspect of the problem fixed by Bob. So for maximum code cleanliness
Bob's fix could be removed, I think Bob alluded to that in one of his
comments on the bug on GitHub.

> The post-pass adjusts the lastIndex ivar of the singleton
> g.app.nodeIndices (ni) object so that all newly-created gnx's are
> guaranteed to be unique, regardless of other loaded .leo files in the
> present invocation of Leo.

It seems that collecting the maximum index value for the gnx timestamp
for a particular c /could/ be done in one of the existing scans, and
that that seems like a less invasive fix than changing the gnx format.

Also, I'm not convinced any non-scan based solutions (other than a
significant number of random bits) can really guarantee no collisions.
The ".leo files from other sources" case basically means you have no
idea what gnxs lurk in the file, unless you look.

Cheers -Terry

[Edward K. Ream]

On Wednesday, October 15, 2014 8:13:25 AM UTC-5, Kent Tenney wrote:

(I'll let go of this soon, I promise)

> not visually acceptable

Who sees them when?
My understanding is that they are only visible when looking
at the xml in a Leo file, am I missing a usage which directly
involves people? My impression is that the xml file hasn't
had people friendliness as a priority.

gnx's appear in external files, so potentially plenty of people might see them.

But your persistence has paid off! An --uuid option could be handled by generalizing ni.scanGnx.  That being so, we could replace everything after the id with a uuid.  That is, instead of "kent.timestamp.n" or "kent.timestamp.fn.n" we would have "kent.<a long uuid>".

Imo, --uuid can not be a default, but we never argue over preferences ;-)

Knowing that gnx's appear in external files, are you still interested in --uuid?

Anyway, this discussion is orthogonal to eliminating the post pass.  In particular, we certainly can not rely on the --uuid option being in effect!

Otoh, the truly part of the project is coming along nicely, so it looks like the post pass will be eliminated.  But first, we must thoroughly test the new ni.scanGnx, ni.tupleToString, and (maybe) support for scanning uuids added to ni.scanGnx.

Edward

[Edward K. Ream]

On Wednesday, October 15, 2014 8:28:05 AM UTC-5, Terry Brown wrote:

> I don't think the post-scan does require Bob's always incrementing timestamp fix, I think the post-scan is a more general solution which addresses the ".leo files from other sources" aspect of the duplicated gnx problem, as well as the "loading the same file twice in one second" aspect of the problem fixed by Bob.

I just don't see how collisions can happen except in automated situations.  The gnx contains the committer id plus a timestamp.  That combination *is* going to be unique in general, unless the timestamps collide, which isn't going to happen except in Bob's case.

> So for maximum code cleanliness Bob's fix could be removed.

Again, I don't see how that statement can be correct.  Each invocation of Leo must be based on a unique timestamp.

> It seems that collecting the maximum index value for the gnx timestamp for a particular c /could/ be done in one of the existing scans, and that that seems like a less invasive fix than changing the gnx format.

Less visible externally, but I really don't like it.  And no, existing scans aren't up to the job because they happen too early, before we know what gnx's have been read.

> Also, I'm not convinced any non-scan based solutions (other than a significant number of random bits) can really guarantee no collisions. The ".leo files from other sources" case basically means you have no idea what gnxs lurk in the file, unless you look.

If that were true, Leo would have been fundamentally broken all these many years.  But no, the combination of id and timestamp is almost always unique.

We must not *ever* reassign gnx's, so any scheme that guarantees no *new* collisions will suffice.  That's what uuids or file numbers do.

Edward

[Kent Tenney]

Ah, sentinels! I live in an @auto only world, I forget about sentinels,
can't comment on the aesthetic importance of their format.

I would see no reason for the <name>. component, would prefer a canonical
uuid from which I can pull date and source machine.

Although automation via LeoBridge may currently be an edge case, it
is at the edge where other software tools engage Leo.

It _is_ a bridge, to the larger community of software tools. As such, it
is very important, and standards compliance a bigger consideration than
code which is local to Leo.

[Terry Brown]

On Wed, 15 Oct 2014 06:47:25 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> On Wednesday, October 15, 2014 8:28:05 AM UTC-5, Terry Brown wrote:
>
> > I don't think the post-scan does require Bob's always incrementing
> timestamp fix, I think the post-scan is a more general solution which
> addresses the ".leo files from other sources" aspect of the
> duplicated gnx problem, as well as the "loading the same file twice
> in one second" aspect of the problem fixed by Bob.
>
> I just don't see how collisions can happen except in automated
> situations. The gnx contains the committer id plus a timestamp. That
> combination *is* going to be unique in general, unless the timestamps
> collide, which isn't going to happen except in Bob's case.
>
> > So for maximum code cleanliness Bob's fix could be removed.
>
> Again, I don't see how that statement can be correct. Each
> invocation of Leo must be based on a unique timestamp.

That's not really an absolute - the absolute here is the statement you
make below, "We must not *ever* reassign gnx's, so any scheme that
guarantees no *new* collisions will suffice." Having a system that
generates always incrementing timestamps locally doesn't address files
from other sources. Of course the full gnx is unlikely to collide when
you include the username etc., but unlikely is not never. When was the
last time anyone got their first choice of username signing up for a
web based service :-) We probably don't want to be relying on Leo
having a small number of users to keep the chances of usernames
colliding in gnxs low :-) :-)

> > It seems that collecting the maximum index value for the gnx
> > timestamp
> for a particular c /could/ be done in one of the existing scans, and
> that that seems like a less invasive fix than changing the gnx format.
>
> Less visible externally, but I really don't like it. And no,
> existing scans aren't up to the job because they happen too early,
> before we know what gnx's have been read.

You know the read code better than anyone, I was just assuming that
there would be opportunity to collect gnx info. on all gnxs in a c
prior to the new post-scan, even if that collection was spread across
different parts of the read cycle. I can certainly see how the post
scan would be the simplest / cleanest to implement.

> > Also, I'm not convinced any non-scan based solutions (other than a
> significant number of random bits) can really guarantee no
> collisions. The ".leo files from other sources" case basically means
> you have no idea what gnxs lurk in the file, unless you look.
>
> If that were true, Leo would have been fundamentally broken all these
> many years. But no, the combination of id and timestamp is almost
> always unique.

"Almost always", vs. "not *ever*". We're definitely targeting
situations which will impact 99% of Leo users zero times in their Leo
using career, there's no argument that the present system is almost
always sufficient.

> We must not *ever* reassign gnx's, so any scheme that guarantees no
> *new* collisions will suffice. That's what uuids or file numbers do.

I'm not seeing how the file number lets me know that the gnx

tbrown.20141015060623.1234.6 does not already exist in the .leo file
being read, particularly when the .leo file was created on another
system.

Cheers -Terry

[Edward K. Ream]

On Wed, Oct 15, 2014 at 9:18 AM, 'Terry Brown' wrote:

>> > So for maximum code cleanliness Bob's fix could be removed.

>> I don't see how that statement can be correct. Each invocation of Leo must be based on a unique timestamp.

> That's not really an absolute...Having a system that generates always incrementing timestamps locally doesn't address files from other sources.

Let's call this the "relativistic" problem. Locally, we can trust
that clocks are uniformly increasing. But for far-away clocks we can
imagine that there times are not really comparable.

But how likely is this? You, Terry, save a .leo file at home, then go
to work and save the same (or another) .leo file and ooooooops, the
two files are based on the same time stamp.

For my money, that case has *zero* chance of happening, not 1%, not
0.1%, not 0.00001%. Zero.

And here are where id's come in. Certainly two *different* people
could have colliding timestamps, no matter how far away, but unless
their id's also collide there is, in principle, no chance of their
separate .leo files colliding.

In short, the combination of id + timestamp really must *never* (zero
percent) collide. Otherwise Leo is broken and we must use another
scheme, maybe uuids.

In the past, we thought the probability was effectively zero. Now, we
know that Bob's edge case exists. But Bob has helpfully restored the
absolute nature of this requirement by adjusting timestamps so the
*never* collide. So for me, Bob's fix is absolute.

> I'm not seeing how the file number lets me know that the gnx
>
> tbrown.20141015060623.1234.6 does not already exist in the .leo file
> being read, particularly when the .leo file was created on another
> system.

It doesn't. Right now I don't see why the file numbers are needed, or useful.

Actually, given that every "base" timestamp is unique, I don't see why
the post scan is needed either. But then I got up at 2:30 am :-)

Given that every invocation of Leo has a (locally) unique timestamp,
can somebody please explain how *any* kind of collision can happen?
Thanks.

Edward

[Edward K. Ream]

On Wed, Oct 15, 2014 at 9:09 AM, Kent Tenney <kte...@gmail.com> wrote:
> Ah, sentinels! I live in an @auto only world, I forget about sentinels,
> can't comment on the aesthetic importance of their format.
>
> I would see no reason for the <name>. component, would prefer a canonical
> uuid from which I can pull date and source machine.
>
> Although automation via LeoBridge may currently be an edge case, it
> is at the edge where other software tools engage Leo.

Imo, there are two completely separate issues here:

1. The *form* of the gnx. Imo, uuid's are visually horrible. They
are designed for the background, not front and center as comments in
an external file. The id field is important, kinda like git blame ;-)

2. The *security* of the gnx (avoiding collisions). Collisions are a
lamentable edge case. We're working on a proper solution. I would be
shocked if uuids are the only solution...

Edward

[Zoltan Benedek]

Hi,

I don't understand much of the topic, but I know a way to reduce the length of an uuid, if it helps.

The result of transformation is a string id of 22 character length, containing only the characters:

0123456789abcdefghijklmnopqrstuvwxyABCDEFGHIJKLMNOPQRSTUVWXY

The result is a unique id as long as the source uuid is unique.

In this way we get an id of 22 character length instead of the 32 character length of the original uuid and we are near to the current 18-19 character length timestamp.n

The transformation is pretty simple, I transform the integer part of the uuid into sexagesimal (base 60) integer, where the digits are the mentioned characters, according to:

http://sexagesimal.objectis.net

Zoltan

[Edward K. Ream]

On Wed, Oct 15, 2014 at 10:29 AM, Zoltan Benedek <benz...@gmail.com> wrote:

> I don't understand much of the topic, but I know a way to reduce the length of an uuid, if it helps...In this way we get [a length] near to the current 18-19 character length [of] timestamp.n

Oh, the power of collaboration. Many thanks for this. base 60 is a
nifty idea, although perhaps not standards-friendly enough for Kent
:-)

I'll keep this in mind. At present, though, I would prefer a
human-readable timestamp. It comes in handy sometimes.

Edward

[Zoltan Benedek]

:-) It was only an idea.

Many thanks for the English correction.

[Edward K. Ream]

On Wed, Oct 15, 2014 at 10:54 AM, Zoltan Benedek <benz...@gmail.com> wrote:
> :-) It was only an idea.
>
> Many thanks for the English correction.

It wasn't a correction. I often shorten or edit comments when replying to them.

EKR

[Terry Brown]

On Wed, 15 Oct 2014 10:21:37 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

My brother Tim in New Zealand sends me a .leo file. Current time
comparison:

Chicago 10:48 am Wednesday
Auckland 4:48 am Thursday

Depending on daylight savings time, there's a 17-18 hour window in
which I have what seems to me to be a 1/(17*60*60) chance of choosing a
timestamp that already exists in the .leo file. Also, Tim's id happens
to be tbrown too, damn it :-)

If we switch the timestamp to GMT instead of local, I know my some of
my personal tools would break, so let's not even go there :-) No, I
don't have a brother in NZ called Tim, but usernames do repeat a lot.
It looks to me like UMN's username index part has past 10,000 for
Andersons, i.e. andeXXXX has stopped working and they've been forced to
go to andXXXXX. Imagine how many jandersons that is in cases where
people go to pick their own username on a local machine :-)

I'm speaking with the advantage of complete ignorance of the read code,
but to my mind the pattern:

- start of read code
- pick timestamp, gnx prefix for new gnxs in this file will be
tbrown.20141014103456.
- while reading file, take note of the maximum index on any gnxs
seen with that prefix.
- when creating new gnxs, start from an index value higher than that
maximum

There seems to be zero chance of accidentally generating a gnx that
already exists in the file. But, perhaps the above is naively
simplistic, I can see that if there's a need to start assigning gnxs
before all the reading / seeing of existing gnxs is done, that's a
problem.

A possible solution, given how unlikely encountering gnxs with the
duplicitous prefix is, would be to proceed as above, and in those
incredibly rare cases, re-do the load armed with the new safe maximum
index value + 1.

Cheers -Terry

> Edward
>

[Kent Tenney]

> perhaps not standards-friendly enough for Kent

:-]

now, I don't want to be the standard-bearer for standards if alone.
Does everyone else prefer an evolved gnx over uuid?

[Terry Brown]

On Wed, 15 Oct 2014 11:08:54 -0500
Kent Tenney <kte...@gmail.com> wrote:

> > perhaps not standards-friendly enough for Kent
> :-]
>
> now, I don't want to be the standard-bearer for standards if alone.
> Does everyone else prefer an evolved gnx over uuid?

:-) I'm still not convinced there's any need to change the existing
gnx. I could live with UUID-1, although it does seem there's a
possible privacy / security issue with UUID-1. I know your MAC address
gets out almost as soon as you turn your computer on, but
leouser13-20141015060623.1234 is basically anonymous, something that
permanently records you MAC address much less so. It wouldn't worry
me, but there are different levels of sensitivity out there.

Cheers -Terry

[Edward K. Ream]

On Wed, Oct 15, 2014 at 11:07 AM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

> My brother Tim in New Zealand sends me a .leo file. Current time
> comparison:
>
> Chicago 10:48 am Wednesday
> Auckland 4:48 am Thursday
>
> Depending on daylight savings time, there's a 17-18 hour window in
> which I have what seems to me to be a 1/(17*60*60) chance of choosing a
> timestamp that already exists in the .leo file. Also, Tim's id happens
> to be tbrown too, damn it :-)

Hmm. Absent the id collision, the probability of overall collision is
zero. But id's were only ever assumed to be unique within a
collaborative project. So there seems to be no way, in general, to
avoid id collisions. This is going to be a *big* problem when two
thirds of the world's population uses Leo!

> No, I don't have a brother in NZ called Tim, but usernames do repeat a lot.

I'm convinced. I've been way too complacent about id's.

> I'm speaking with the advantage of complete ignorance of the read code,
> but to my mind the pattern:
>
> - start of read code
> - pick timestamp, gnx prefix for new gnxs in this file will be
> tbrown.20141014103456.
> - while reading file, take note of the maximum index on any gnxs
> seen with that prefix.
> - when creating new gnxs, start from an index value higher than that
> maximum
>
> There seems to be zero chance of accidentally generating a gnx that
> already exists in the file.

Ah. at last I see.

You are assuming that the combination id.timestamp could have
arbitrary collisions. In that case:

a) Bob's timestamp hack is not needed and

b) A post-pass is needed to find the maximum n that does not occur.

Note that only gnx's with the *particular* id.timestamp on which this
copy of Leo is based need to bump the maximum number computed by the
post pass.

> But, perhaps the above is naively simplistic.

It seems rock solid to me. The post pass frees us from *any*
assumptions about ids and timestamps.

There is one last question: what to do about pasted trees? If it's a
normal paste, the gnx's of all nodes are reassigned. No scan needed.

And what if the user does paste-retaining-clones? I think the only
sane assumption is that the user *expects* that gnx's may
match/collide. Otherwise, what's the point of the paste? Again, no
scan needed.

> I can see that if there's a need to start assigning gnxs before all the reading / seeing of existing gnxs is done, that's a problem.

Happily not, except possibly the root vnode. Reading happens before
anything else, so the after-read post-pass should be safe. If
necessary, we can treat the hidden node as a special case. I don't
remember how it gets created. In fact, its gnx probably is never
used...

> A possible solution, given how unlikely encountering gnxs with the
> duplicitous prefix is, would be to proceed as above, and in those
> incredibly rare cases, re-do the load armed with the new safe maximum
> index value + 1.

No reloading should be necessary. Usually *no* previously read nodes
will collide with the id+timestamp pair, so the starting index will be
zero (or one). No need to add a special case.

This is great. My picture has completely changed. Now, we *never*
assume the id+timestamp pair is unique. We act accordingly by running
the post scan as at present. As Bob says, adjusting timestamps is
never needed.

This seems like a good (if unexpected) resolution, one that requires
nothing but the *existing* post-pass. Let me know if I've forgotten
anything :-)

Edward

[Terry Brown]

On Wed, 15 Oct 2014 11:43:59 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

[snip]

> > But, perhaps the above is naively simplistic.
>
> It seems rock solid to me. The post pass frees us from *any*
> assumptions about ids and timestamps.

I meant simplistic in terms of my thought that maybe the
scanning-for-max could be done during existing passes rather than in a
separate post-pass, just to minimize the performance hit. But it will
be much easier to feel confident nothing got missed with a post-pass,
so that's probably the way to go as long as the impact's not
significant.

[snip]

> This seems like a good (if unexpected) resolution, one that requires
> nothing but the *existing* post-pass. Let me know if I've forgotten
> anything :-)

No, I think we're good. So we believe Bob's always increasing
timestamp is redundant and could be removed, but other than that, I
think we're literally unique now :-)

Cheers -Terry

[Segundo Bob]

On 10/15/2014 03:57 AM, Edward K. Ream wrote:
> This is an Engineering Notebook post. Feel free to ignore it unless you
> have a deep interest in bug #69.

You mean Issue #35, not Issue #69.

Issue #69 is "leoBridge leaves .leo open"
Issue #35 is "leoBridge sometimes assigns the same GNX to two distinct
vnodes"

Issue #69 prevented my tests for Issue #35 from running. That is why I
needed to have it fixed.

>
> Bob has just reported that the post scan works for him.

No, I reported that your fix to issue #69 "leoBridge leaves .leo open"
works for me. This has nothing to do with the post scan---and in fact,
I'm afraid there are problems with your post scan which I will describe
shortly on the Issue #35 thread where it belongs.

In your back and forth with Terry Brown North this morning, I agreed
with Terry and I'm relieved he finally convinced you on the major issues.

--
Segundo Bob
Segun...@gmail.com