Fwd: New PieceTable property for remote changes.

Hi everyone,
                  I stared this conversation with Marc offlist. I'm
continuing it on list. Tomas, feel free to chime in whenever you have
time.

The conversation started when I suggested we create a new attribute
"remote" with the value of "n" where nth remote user. We would use the
prorty to color text and to provide information as to who created
which piece text via a right click context menu.

uwog then thought that revision marks already did all this and a lot more...

Cheers

Martin

---------- Forwarded message ----------
From: Martin Sevior <msevior@gmail.com>
Date: Thu, Jul 24, 2008 at 11:56 PM
Subject: Re: New PieceTable property for remote changes.
To: "J.M. Maurer" <uwog@uwog.net>

On Thu, Jul 24, 2008 at 11:47 PM, J.M. Maurer <uwog@uwog.net> wrote:
>
> On Thu, 2008-07-24 at 23:37 +1000, Martin Sevior wrote:
>> Hi Marc,
>> My lack of enthusiasm for this idea is based on me trying
>> to understand TF's PT code to do with revisions. It's not the least
>> bit clear that what we think is happening actually is happening. For
>> example I *thought* that every operation with Revision Marks enabled
>> actually carries around a revision mark attribute.
>
> operation == CR?
>

No, the CR has the property but it didn;t get carried into the
Attributes/ of the span. So for example if I turn on revision marks
then insert some text, the the attribute "revision" exists with the
value 1 is exprted to the listeners but it is not carried around in
the text span I insert.

> If so, how are Rev. Marks stored right now in the PT ?
>

I'm not sure. I'm still trying to work that out. I think they're
document level property that is interogated on every PT change.

>> It turns out this was the not the case. Part of my surgery on the PT so far is to make
>> sure this property IS set for at least remote revision marks.
>
> What property do you actually set on 'what' _exactly_ (talk in code form
> please, maybe then I have an easier time to understand :p)
>

The attribute is "revision". It is meant to tell you the level of each
revision. I've have been using "level" to represent different users in
an abicollab context but actually I think TF's code is more subtle
than that. I believe his code that level 1 is the first set of
revisions. Level 2 is the second, level 3 is the third and so forth.
Note that this assumption is that each level comes after each other.
ie there is a heiracy of revisions. We can accept all revisions up to
level n for example.

Note these semantics are different from what we do in abicollab where
all users are in principle equal.

So I'm not sure our current revision marks make sense in the context
of abicollab now.

We should dump this conversation onto abiword-dev BTW

Cheers

Martin

>> I think
>> that TF makes many, many implicit assumptions that there is only one
>> set of revision marks present at one particular PT context, which
>> makes perfect sense from his point of view of when he wrote that code
>> but screws us now when we want to record who wrote what when.
>
> How can there be more than 1 set of revision marks on 1 PT context in
> our case? Only one user will have touched 1 part, just like in the old
> case. I have the feeling i miss something :)
>
>> I think he did it to avoid the elaborate potential mess with the
>> document format you talked about.
>>
>> Actually from the point of view of the total document size, it doesn't
>> make that much difference in memory, but it likely greatly expands the
>> size of the document file if we carry around that sort of history.
>>
>> Part of my reason for wanting to do the property marking is because it
>> maps much more closely to how abicollab works. I still haven't worked
>> out how tf's revision marks really work. Only that they don't do what I
>> thought they did.
>
> Cheers1
>
> Marc
>
>> Cheers!
>>
>> Martin
>>
>> On Thu, Jul 24, 2008 at 10:51 PM, J.M. Maurer <uwog@uwog.net> wrote:
>> >
>> > On Thu, 2008-07-24 at 22:10 +1000, Martin Sevior wrote:
>> >> Hi Marc,
>> >> Revision marks suck when you try to delete stuff because
>> >> the text gets crossed out rather than deleted.
>> >
>> > That's why I mentioned the suggestion of adding a switch, to not
>> > _display_ the deleted (or otherwise modified) text.
>> >
>> >> I finally got the
>> >> revision marks coming out as different colors but then realised that
>> >> we have significant issues with revision marks and deletes. Since the
>> >> text isn't deleted, our adjustment calculations are incorrect with
>> >> revision marks on.
>> >
>> > Oh jolly :-P Where do you plan on fixing this? I think this needs to be
>> > fixed in abicollab's packet length calculation functions.
>> >
>> >> I still prefer the different colors and the remote property since that
>> >> info is different from Revision Marks. It's actually a different
>> >> feature.
>> >
>> > I don't see how it is different (in fact, it is _exactly_ what we
>> > want):
>> >
>> > * revision marks track which user changes what
>> > * with abicollab we want to track who changes what
>> >
>> > :) In fact, it is even more powerful: we also keep track of what the
>> > previous content was, which rocks for "web based diff viewing"!
>> >
>> > Using rev. marks for this really sets of a party in my head (note: I
>> > used to dismiss it, because it also shows crossed out text and such; but
>> > we can make that a setting). Think about it :)
>> >
>> > Marc
>> >
>> >> Anyway will chat on IRC about this.
>> >>
>> >> Cheers
>> >>
>> >> Martin
>> >>
>> >>
>> >> On Thu, Jul 24, 2008 at 8:25 PM, J.M. Maurer <uwog@uwog.net> wrote:
>> >> >> IMO every such solution is a bit annoying. How about always enabling our
>> >> >> 'revision tracking' feature, and making sure that it can detect where
>> >> >> the edit came from (local or remote). We already have that info in the
>> >> >> CRs now, so we wouldn't need any wire or file format change. Every is in
>> >> >> place *right now*. And finally: this feature was designed _explicitely_
>> >> >> to do what we want now. We just didn't know it back then :)
>> >> >
>> >> > The only issue left I see with this, is that when you enabled the
>> >> > 'revision coloring', it also shows the text that "was there previously".
>> >> > That would be a bit annoying in a collaboration session, if you 1) do
>> >> > want to see the colors 2) don't want to see all the 'old' text.
>> >> >
>> >> > We could just add an extra switch to 'show the colors, but hide the old
>> >> > crap'.
>> >> >
>> >> > The cool thing with this is that all this revision info is currently
>> >> > stored in our file format. That means that the webinterface should also
>> >> > be able to parse it out, and show a nice colored diff in the webapp :)
>> >> >
>> >> > Marc
>> >> >
>> >> >
>> >
>> >
>
>
Received on Thu Jul 24 16:06:22 2008