|
Hi Patrick,
On 20.09.2012 14:07, Patrick Durusau wrote:
Svante,
Just quickly.
You need to stop eliding over what you mean by "change."
Every operation on the document results into a change of state. Each
(stored) operation reflect a change.
From
below:
Might be philosophical, as every operation
creates a new independent
document state. Therefore two (or more) sequential operations
changing
the same data, could be interpreted either as two (or more)
independent
changes of the document state or as a change of a change.
After realizing both views are equivalent it is much easier to
work
solely with the prior model, where each change is independent
and
movable along the sequence of operations (presuming to do the
required
OT adaption during movement, i.e. whenever passing a
create/delete
operation that influence the position of the moving operation
de/increase the position integer).
Now you imply that a change is not a change unless the
"create/delete operation ... influence[s} the position of the
...the position integer."
I was former talking about multiple operations, which can be seen as
change of a previous change and latter I had been talking how to
rearrange changes (operations) in the queue of operations (your
quote above).
Which negates the idea of tracking changes to page formatting
(which we track now), changes styles applied to text (a requested
feature), none of which impact the position integer.
For that matter, it includes changes made as I insert "new" text
because the end position pointer is expanding as I type and
decreases if I delete part of the inserted text, before some
designation of "state."
When does the insertion/deletion of *new* text become fixed with
regard to OT change tracking?
I am not certain, if I understand the question, but it seems you are
puzzling, when an operation should be created by the application,
when a user edits a document in its front-end. (see answer below)
When
forward progress of the text stops? When I stop deleting the
inserted text? When the cursor has moved off the inserted text
(after deletions/additions)? Or the cursor has left the inserted
text for more than 5 seconds? After a save?
Why shall we care? This is absolutely an implementation detail of
the application, all we have to care about is that similar changes
are able to be reflected by different set(s) of operations, which
all have in common that they have the same information set,
resulting in the end into an equal change.
For instance, instead of three operations:
- insert "a" in paragraph 1 at position 1
- insert "b" in paragraph 1 at position 2
- insert "c" in paragraph 1 at position 3
The application might as well sent one operation:
- insert "abc" in paragraph 1 at position 1
AFAIK Google Docs is pushing every change right away to the
server, like editing in a field using AJAX.
Changing
the position pointer (start or end) may be part of a definition of
change but it is a fairly crude one.
Only if the position pointer is part of the document state to be
changes, AFAIK OOo is saving it into the settings.xml properties.
Otherwise I refer to the beginning of this mail, a change is
reflected by an operation call upon the document.
Hope
you are having a great day!
Patrick
Hope you are having a great day as well!
Svante
On 09/20/2012 05:49 AM, Svante Schubert wrote:
Hi Patrick,
On 19.09.2012 17:04, Patrick Durusau wrote:
Svante,
On 09/19/2012 08:35 AM, Svante Schubert wrote:
Hi Patrick,
<snip>
That is at what time does the state of
the text become "fixed" so that
change tracking is engaged again?
With "fixed" you might as well think about a
compression/condensation of
operations. For example, if someone inserts a word and
deletes it again,
it will not occur in the CT, although there had been two
operations.
That was my question.
You are presuming a model that does not track changes to
changes.
Might be philosophical, as every operation creates a new
independent
document state. Therefore two (or more) sequential operations
changing
the same data, could be interpreted either as two (or more)
independent
changes of the document state or as a change of a change.
After realizing both views are equivalent it is much easier to
work
solely with the prior model, where each change is independent
and
movable along the sequence of operations (presuming to do the
required
OT adaption during movement, i.e. whenever passing a
create/delete
operation that influence the position of the moving operation
de/increase the position integer).
Which is one presumption but perhaps not
the one that the TC desires
to make.
The TC is likely to favor the easiest and efficient model being
offered.
Can think of compression/condensation of
operations but that means the
CT syntax has to record multiple changes, say make bold and
italic
instead of separate operations of bold, then italic (on the
same text).
From a abstract high level view, changing the style on text is
nothing
more than an change of properties on a sequence of the document.
Someone
might change a single property or multiple properties. Latter
might be
done via operations by either passing all properties along or
defining a
set beforehand. Someone might even have the vision that some
style sets
are being defined before the operations occurs (to follow our
convention
over configuration approach), either within the document (as a
given
style set) or preferable within the ODF specification, by "style
blends"
from the application vendors. For instance, the "heading 1"
style set
might be defined before hand, instead of passing the styles for
every
document being opened.
Various compressions are thinkable, all they have to have in
common is
to keep the information set equivalent.
And, it means we have to define when
compression/condensation occurs
and how it is recorded in syntax.
Uncertain yet, if we have to be necessarily such strict. We
definitely
have to define what operations are equivalent. We could even
come up
with a normalized form of operations (the most efficient form of
operations to be exchanged).
Not objecting to your answer but it
leaves out a lot of detail. ;-)
Sure, just wanted to keep the mail short ;)
Hope you are having a great day!
Patrick
Hope you are having a great day as well!
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail:
office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
office-collab-help@lists.oasis-open.org
|