Re: Fwd: New PieceTable property for remote changes.

Hi Tomas,
              Thanks very much. This helps a lot. Marc and I continued
our discussion on IRC. The result of which was to use a new attribute,
"author" that contains the UUID of the remote author for a peice of
text. This will allow us to initially assign a color for for each
authors text, (thus providing the functionality that Gobby and
subethaedit provides) as well allowing the user to idientify who was
responsible for each piece of text.

We reached the conclusion that later this could be used to enhance
revisions marks as suggested by Tomas.

Cheers

Martin

On Fri, Jul 25, 2008 at 3:30 AM, Tomas Frydrych <tf@o-hand.com> wrote:
>
> Hi guys,
>
> Martin Sevior wrote:
>> 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.
>
> Right, it's been a while, but just a quick top-post; it works something
> like this:
>
> 1. each revision represents a set of changes ('set' in the mathematical
> sense, there is no order to the changes, or anything like that).
>
> 2. The revision sets are stacked up into a sequence; once revision N is
> started, revisions < N are closed, and can no longer be modified.
>
> 3. Each change is stored in the 'revision' attribute; it consists of a
> numerical id identifying the revision set the change belongs to, a type
> (insertion, deletion, change) and in case of a change, the properties
> that were changed; a single 'revision' attribute can hold multiple
> changes belonging to different attributes.
>
> 4. IIRC, the biggest challenge as far as the PT is concerned was the
> handling of deletion, since with revisions on, there is no actual
> deletion happening, the text stays and is only marked as deleted.
>
> As noted by Martin, the revision mechanism is built on the premise that
> the change sets are sequential, and as such, is not suitable for the
> remote tracking. In fact, it struck me when you guys first started
> working on the collab stuff, that the revisions are a special case of
> the more generic problem that the collab code addresses, and, if someone
> had the inclination, it should be possible to reimplement the revisions
> in terms of the collab infrastructure.
>
> For what it is worth, I think redoing the revisions on the top of
> abicollab would be desirable; it would simplify maintenance, and allow
> you to share the same code in the layout engine for the drawing, and I
> suspect you would end up with code that is more robust. (Also, it should
> be possible to do proper document diffing around the abicollab
> infrastructure, but that is another topic.)
>
> Tomas
>
>>
>> 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 23:59:00 2008