|
|
(14 intermediate revisions by one other user not shown) |
Line 1: |
Line 1: |
| <h2>OverView</h2> | | <h2>Whiteboard</h2> |
| I have decided to set up this page as my log for the google summer of
| |
| code project, formalising the protocol for inkboard communication
| |
| and converting the library to pedro.
| |
|
| |
|
| <h2>Predicted TimeLine</h2> | | <p>I had intended on a working prototype at this point of the program, however an unexpected delay came up with a bug in server implementations which needs to be resolved, I am about to go on a holiday until the 27th and will not be able to undertake any more development until this time</p> |
| | |
| | <p>Throughout the time of summer of code I had expected to complete a release worthy implementation of the whiteboard extension, however as I am yet to recieve the first payment from the program. I had to spend a significant time that i had planned on using on the whiteboard project in finding a job and working to get the money I had budgeted to recieve from google, which has seriously affected my timeline.</p> |
| | |
| | <p>Following is a Todo list of the tasks I have yet to do, and a timescale in which i plan to implement them</p> |
| | |
| | <h3>TODO</h3> |
| | <ol> |
| | <li>Finalise manually serialising incoming message - 2 days, 30th August</li> |
| | <li>Apply incoming changes to the whiteboard - 5 days, 4th September</li> |
| | <li>Finalise and implement MUC session establishment - 6 days, 9th September</li> |
| | <li>implement conflict resolution - 5 days,14 September</li> |
| | <li>I will give 2 weeks afterwards dedicated to making sure the whiteboard is release worthy</li> |
| | <li>Easy to follow step-by-step whiteboard tutorial documentation, specially how to use it on a GoogleTalk account (GoogleTalk is Jabber).</li> |
| | </ol> |
| | |
| | <p>Given this timescale I fully expect to have a release worthy implementation for October</p> |
| | |
| | <h4>Progress</h4> |
| | <ol> |
| | <li>Serialising Incoming messages - done, jabber.org ensures the in-order processing</li> |
| | |
| | <li>Apply Incoming Changes - 80% complete, need to handle special case nodes such as defs, and transformation matrices, plus ordering of objects</li> |
| | |
| | <li>Conflict resolution - 90% complete, need to finalise rollbacks</li> |
| | </ol> |
| | |
| | <h3>Done</h3> |
| <ul> | | <ul> |
| <li><h3>Deliverable 1 - Friday, 30th June</h3> | | <li>State and Session Handling<li> |
| <p>Extend and finalise the initial draft of the protocol specification started
| | <li>Peer to peer session establishment</li> |
| by David Yip (/src/jabber_whiteboard/protocol/protocol.tex), intergrating as much of the standard protocol underdevelopment at http://wiki.jabber.org/index.php/Psi_Whiteboarding which must include the following</p>
| | <li>Whiteboard clients broadcast all changes to the document</li> |
| <ul><li>Specification for conflict resolution</li>
| | <li>Developed a formal protocol in liason with joonas of the psi project location : http://debrowse.com/whiteboard/wb.xml</li> |
| <li>Use Case for peer to peer and Multi User Chat session establishment</li> | |
| <li>Use Case for communication of edits between sessions</li> | |
| <li>Listing of valid message types</li> | |
| <li>State transition diagram of Inkboard Clients</li>
| |
| </ul> | | </ul> |
| </li>
| |
| <li><h3>Deliverable 2 - Friday, 14th July</h3>
| |
| <p>Develop and finalise the XML schema that is implemented by the inkboard clients, this will define the valid message types that may be transferred</p>
| |
| </li>
| |
| <li><h3>Deliverable 3 - Friday 28th July</h3>
| |
| <p>A basic inkboard client developed using the perdo XMPP client, must be stable enough to be integrated with the trunk, that contains at least the following</p><ul><li>Initialisation and Destruction of multi user and peer to peer session</li><li>Basic communication of changes between documents</li></ul></li>
| |
| <li><h3>Final Deliverable - Monday 21th August</h3>
| |
| <p>End of Summer of Code project, a fully stable inkboard intergrated into the inkscape trunk, ready for inclusion in the release of .45, features to include:
| |
| <ul><li>Conflict Resolution</li><li>Local Undo mechanism</li></ul></p>
| |
| </li>
| |
| </ul>
| |
|
| |
| <h2>Notes</h2>
| |
|
| |
|
| <h2>Project Log</h2>
| | <p>Sorry to all who expected the whiteboard to be working at a time before this, for the reasons given above I have been unable to stick the the original schedule. However I fully plan on sticking to the timescale given and finishing the whiteboard. And of course after the whiteboard is complete I fully intend to carry on working on its, or other aspects of inkscapes future development</p> |
| <em>2/06/05</em>
| |
| <p>Still cant decide on a protocol for MUC session establishment, I think this will need to be voted, it has quite large effects on implementation. there has been talk about limiting the undo queue needed which is rather a large implementation detail. I am late with the first deliverable, but I think it was expected with how late I was starting the project, It has also been slowed down trying to get multiple parties to agree, It will certainly be ready in time along with the XML schema</p> | |
| <em>1/06/05</em>
| |
| <p>Discussed some of the last issues with the JEP, MUC session establishment, I think we need to have another conference. Issue include service discovery, the sandbox and actual transfer of in band images</p>
| |
| <em>30/06/05</em>
| |
| <p>I actually wont need to patch ejabberd, somone has sent the patch, hopefully it will be introduced into latest stable, darcs is being incredibly annoying to install</p>
| |
| <em>29/06/05</em>
| |
| <p>Joonas and I have agreed on most protocol issues and decided to work on the same JEP. Some of the tradeoffs, I have agreed that <new> elements should be sent as raw svg, which means I have to compile change events to new svg elements. The other major one being that we will not use the id attribute to track elements, instead a whiteboard specific id given during the creation of an object</p>
| |
| <em>28/06/05</em>
| |
| <p>the first draft of the protocol used a revised version of the old inkboard session negotiation protocol, I think CAP / disco are more suitable for the initial stages of session establishment, so I am researching this to hopefully commit to a revised protocol soon<br />
| |
| I also followed up the issue of presence stanzas being incorrectly ordered on ejabberd servers, it look like I would have to submit my own patch to resolve this</p>
| |
| <em>27/06/05</em>
| |
| <p>Dicussed with joonas about the integration of the jabber.org and my protocol, so far there are only 2 issues, address of elements, which I need to discuss with david yip, and the sending of native svg through the protocol. which is hopefully easy to resolve</p>
| |
| <em>26/06/05</em>
| |
| <p>Started my draft of the whiteboard protocol, for now I will keep an updated copy at http://debrowse.com/protocol.html<br />
| |
| Jabber.org hosted a discussion on whiteboarding issues, it went quite well, as both peer to peer and muc with client side synchronisation are looking to be supported, with an option for muc with a server component</p>
| |
| <em>25/06/05</em>
| |
| <p>Have had a few problems integrating a jabber_whiteboard board specific gui to the pedro client, im going to put any development work on hold until I can get the protocol drafted</p>
| |
| <em>24/06/05</em>
| |
| <p>Managed to fix the windows build, it ignored makefiles_insert
| |
| and compiled old code, there are issues with compilation against older
| |
| versions of gtk.</p>
| |
| <em>23/06/05</em>
| |
| <p>I spent today merging the INKBOARD_PEDRO branch with the trunk, all works well on linux, I have disabled inkboard to be built on windows for the time being as there is some rather confusing compile errors, which I will hopefully fix tomorrow</p>
| |
| <em>22/06/05</em>
| |
| <p>After discussion with David Yip and Joonas of the jabber.org SoC project, A proposal has been set for conflict resolution, I have started extending the protocol document that can be found in the pedro branch. We are setting up a time convenient for a whiteboard related conference in the next week or so</p>
| |
| <em>21/06/05</em>
| |
| <p>I have finished uni and can start working full time on the protocol / lib
| |
| conversion. We have decided to integrate the whiteboard gui into the pedro
| |
| gui. I am starting my work with adding the whiteboard gui into pedro, and
| |
| defining groupchat and peer to peer initialisation protocol</p>
| |
Whiteboard
I had intended on a working prototype at this point of the program, however an unexpected delay came up with a bug in server implementations which needs to be resolved, I am about to go on a holiday until the 27th and will not be able to undertake any more development until this time
Throughout the time of summer of code I had expected to complete a release worthy implementation of the whiteboard extension, however as I am yet to recieve the first payment from the program. I had to spend a significant time that i had planned on using on the whiteboard project in finding a job and working to get the money I had budgeted to recieve from google, which has seriously affected my timeline.
Following is a Todo list of the tasks I have yet to do, and a timescale in which i plan to implement them
TODO
- Finalise manually serialising incoming message - 2 days, 30th August
- Apply incoming changes to the whiteboard - 5 days, 4th September
- Finalise and implement MUC session establishment - 6 days, 9th September
- implement conflict resolution - 5 days,14 September
- I will give 2 weeks afterwards dedicated to making sure the whiteboard is release worthy
- Easy to follow step-by-step whiteboard tutorial documentation, specially how to use it on a GoogleTalk account (GoogleTalk is Jabber).
Given this timescale I fully expect to have a release worthy implementation for October
Progress
- Serialising Incoming messages - done, jabber.org ensures the in-order processing
- Apply Incoming Changes - 80% complete, need to handle special case nodes such as defs, and transformation matrices, plus ordering of objects
- Conflict resolution - 90% complete, need to finalise rollbacks
Done
- State and Session Handling
-
- Peer to peer session establishment
- Whiteboard clients broadcast all changes to the document
- Developed a formal protocol in liason with joonas of the psi project location : http://debrowse.com/whiteboard/wb.xml
Sorry to all who expected the whiteboard to be working at a time before this, for the reasons given above I have been unable to stick the the original schedule. However I fully plan on sticking to the timescale given and finishing the whiteboard. And of course after the whiteboard is complete I fully intend to carry on working on its, or other aspects of inkscapes future development