On 03/21/2013 12:52 AM, Philip Peitsch wrote:

Is there a delivery road-map, or a backlog somewhere of the planned features? I'm in the middle of sorting out the various requirements I have for the editing behaviours and am basically trying to answer where to best start.

We are at a point on the roadmap where we deliver features, but have not written a follow up roadmap yet. Roughly our roadmap is to add all odf features eventually and by priority of customer wishes.

The complete features I will need to support in the next few months are:

* Paragraph add / delete * Page-break add / delete * Table add/delete (rows & columns as well) * Character range changes (i.e., modifying the character styles of a selected range of text) * Paragraph style changes (already covered by your work in some fashion) * Paragraph alignment changes (create a new style based on an existing, modify the alignment) * Bulleted & numbered list creation * Image insertion & removal * Cut/Copy/Paste (both WebODF => WebODF, external => WebODF, and WebODF => external) * Page view (as opposed to the "continuous" view currently supported. vandenoever mentioned he had some ideas on how to fix this)

Yes for pagination there is a solution which will work well for all pages without columns. For pages with columns either more complex javascript or good support for CSS Regions is required.

Is the stuff you are doing for the collaborative editing straight-forward enough that I (and you) would benefit if I implement these editing operations using that framework, or is my life going to be much simpler to implement the DOM changing independently?

That is a very sensible question. And I can give you a counter question: will you need to support undo and redo? If you do, then you need a way to serialize the operations that you perform on the dom and create a reverse operation. And that is also a requirement for collaborative editing. In collaborative editing there is the option to allow to swap the order operations, but that is not a requirement for the operations.

Ideally, if you have a roadmap and timeline that aligns partially with what I'm going to need to build, I can choose tasks that won't tread on your toes or re-do work you are already scheduling and planning for. It would hopefully also mean there is the best chance that the code I write is useful to the WebODF project in general, rather than a standalone hack branch which I'd prefer to avoid if at all possible :). I'm open to any suggestions on how I might tackle this in a way that will make it possible for you to integrate the work back in if you think it might be useful. Is it possibly a good idea for me to start to plan some of this on a public wiki somewhere if you have specific design suggestions or feedback?

We work quite agilly and all operations have their own file. http://gitorious.org/webodf/webodf/trees/master/webodf/lib/ops In fact, our operations do not currently have the reverse yet, but that will come. I think that organizing DOM operations is not a difficult overhead though and a nice way of modularizating the code.

Please don't feel pressured about this either way. If your time is better spent doing things other than helping me design/plan/integrate this, I'll figure something out on my own. I'm just conscious there is a greater risk that the resulting code I produce won't be able to be easily contributed back if I just make it up on my own :)

I think it's a worthwhile 'investment' of time to help you. :-) That's a large part of a community project. Of course there is an effort on both sides to coordinate this, but that is fine. As to a roadmap for your features, I think that simply implementing the operations is the best thing you can do. In our current use case they will not bite when not used anyway so there is also little need to keep multiple branches that are hard to synchronize. Even if there are separate branches, since the operations are separate files, that should not be a big problem. Cheers, Jos