OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: IRC log from today's meeting - 2015-11-04

Our next meeting will be on the 18th of November:

The teleconference login data for next call will be found in the OASIS calendar event:
Phone numbers are listed in the calendar invite:  https://www.oasis-open.org/apps/org/workgroup/office/calendar.php 
Chat room for meeting is at:  http://webconf.soaphub.org/conf/room/odf

Please find the IRC log of today's meeting below: 
Attendees: Peter Rakyta, Svante Schubert
[16:29] Svante: Hello Peter
[16:29] Svante: Just entered the call! :
[16:29] Peter Rakyta: Hi Svante
[16:30] Svante: https://lists.oasis-open.org/archives/office-collab/201511/msg00000.html
[16:32] Svante: I got in contact with Marijn http://marijnhaverbeke.nl/blog/collaborative-editing.html
[16:34] Svante: He got 50k to opensource his editor recently and lives in Berlin as I do (see https://www.indiegogo.com/projects/prosemirror#/)
[16:34] Svante: Seems he is now busy in answering his stakeholders from the kickstarter project 
[16:37] Svante: Marijn pointed out https://github.com/ottypes/rich-text and I am in contact with the core developer as well to exchange views and get/give feed-back
[16:40] Svante: I started to fork the Apache ODF Toolkit (incubating) fork of Open-Xchange at github: https://github.com/svanteschubert/ox-odfdom
[16:42] Svante: It is just a fork of a subdirectory of their office repository, but git is able to keep history and still pull changes - http://stackoverflow.com/a/24577293
[16:43] Svante: Currently removing the dependencies to have a out-of-the-box operation based example available
[16:47] Svante: How does a merge work?
When we come back after weeks we need to merge our changes to the same document.
Therefore our sequence of changes have to look identical in the end.
Again I like the concept of GIT and think of pulling the changes.
If you write "Hello" and I write "World!", the order depends who is given precedence.
Think of our change queues as card decks. One card deck is lain on top of the other and one card at the time is moved down the deck by exchanging two cards and checking for OT effects.
[16:51] Peter Rakyta: first change: hello word
[16:51] Peter Rakyta: second change: hello my world
[16:52] Svante: ^^second change is "add @ position 6 ' my'"
[16:54] Svante: If you would revert the order of the two operations, the former first operation would be split
[16:57] Svante: " My" @ pos 1
Hello @ pos 1
World @ pos 8
[16:58] Svante: When the two former operations were created by different users a normalization (merging them together) would not be correct.
[16:58] Peter Rakyta: My point is, that if you do not introduce a dependency tree to forbid to exchange the order of the overlapping changes, than the things get quite busy
[17:00] Peter Rakyta: not busy, but complicated
[17:01] Svante: It might be more complex, but still it is straigtforward. Only to adjacent operations have to be checked for OT influence before exchanging them in order
[17:03] Svante: The changed order is equal to let the two operations occur in different order of time
[17:03] Svante: The sequence of changes (or operations) are ordered in time.
[17:07] Svante: Peter explains the reason to avoid this is that if USER A is adding "Hello World" and USER B inserts " my". But USER A removes his insertion the application behavior should be to delete the insertion of USER B as well, as alone it likely does not make sense. Suggested Application Convenience Behavior.
[17:10] Svante: The reason I do not want to forbid the exchange of overlapping changes is that there is a feature of moving changes belonging together through history.
[17:10] Svante: Like editing a specification under one bug ID. Later turning out these changes should not belong to the next version, but should be kept within the document.
[17:11] Svante: Moved through the sequence of changes ordered in time, even after the pointer marking the latest change.
[17:11] Svante: Creating a "future branch". Like not only accept/reject, but allowing postpone. Only a possible feature in the future for office applications...
[17:13] Svante: The exchange of two adjacent operations will only not work if the timeline: CREATE - MODIFY - DELETE would be broken.. 
[17:13] Svante: ^^in other words: the lifecylce have to be kept
[17:15] Svante: byebye

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]