On Feb 20, 2009, at 10:10 PM, Florin Ciubotaru wrote: > Hi Vincent, > > Thanks for the reply. > See bellow: > > Vincent Massol wrote: >> Hi Florin, >> >> On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote: >> >> >>> Hi devs, >>> >>> Due to some critical bugs and missing features, the release was >>> postponed for a long period. >>> >>> Still the development process is way ahead of what was intended for >>> XWord 1.0 >>> This is how the old roadmap looked like: >>> http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversion >>> >>> As you can see XWord 1.0 was intended to be an export to wiki tool >>> and >>> only XWord 1.1 should enable editing wiki pages. >>> Sorry for not keeping you up to date on the mailing list. >>> This is the new roadmap for XWord: >>> - 1.0 M1 >>> >> >> What is the release date planned for 1.0M1? >> > This is not established. In terms of development XWord is ready for > release. Manual publishing works fine, automatic doesn't. > What we need to to is to see if OW2 can be used as a location for the > clickOnce binaries and manifests. It also depends if you want CI > before > or after M1.
For M1 we don't need anything automated. We need to release ASAP so anything releasable should be released. I don't know what clickonce library are. >>> - Wiki Explorer - done >>> - Attachment Upload - done >>> - Attachment Download - done >>> - Export word documents - done >>> - Edit/Save wiki pages - done >>> - Save pages with user specified syntax - done >>> - Protect essential pages from editing - done >>> >> What is this? >> > This means that you cannot open in Word some specific pages that > provide > functionality to the wiki. Eg: The pages in XWiki, Stats or Blog > spaces. > Note: There is no api for identifying these pages. This was ok for > XEclipse as it targets developers and wiki syntax editing, but in the > case of XWord which is created for non-technical users, a method to > protect these pages is required. I don't understand. If the user has view rights then he should be able to view any page even if they are in the XWiki space. If they have edit rights on the page then they can edit the page. >>> - Export using filtered html - done >>> >> >> Isn't this already done by the Office importer HTML cleaner? We'd >> need >> to find ways so that you can reuse this to prevent code duplication >> (and it's a complex domain). >> > Word can output html in two modes: filtered or not filtered. > The filtered html size is about 10% of the not-filtered html, but it > losses data from embedded elements(diagrams, shapes, expressions and > charts). > Additionally I created filters and adapters that are applied at > different stages of the conversion. > The steps are: > Saving a document to the wiki: Word Supported Format -> WordML <-> > HTML > -> WikiSyntax > Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] > The conversion from and into wiki syntax is done on the server. I can > program against all the other data formats and set options on the > transformation from one format to another. For this I'm using Word API > or custom developed functionalities. IMO this has a better chance of > success then a server oriented filter. > Note that Word html is different from OOo html, so the filters that > could be used for XWord are the filters implemented for the "Paste > from > Word" feature of the WYSIWYG. If we get these filters to provide high > quality bidirectional saving and data preservation, then yes we can > use > then for XWord. Yes I'm talking about the WYSIWYG copy/paste filters. But I think they are basically the same one as for oOo but with additional filtering done (Asiri correct me if that's not correct). In any case since we support copy/paste in the wysiwyg then we already have them or will have them. >>> - Export with non-filtered html - buggy >>> - Deployment and infrastructure - problematic because it uses >>> ClickOnce. >>> - 1.0 M2 - 2-3 weeks from M1 >>> - Solve as many reported bugs >>> - Improve html filters >>> - Introduce the XML-RPC communication mode >>> >> >> What is this? Any advantage of using XMLRPC vs REST? (I don't have a >> preference but since we have both I'm wondering). >> > XWord does not depend on a specific implementation for client-server > communication. I can be easily changed. > What is important is to have a fully featured API. I will create a > separate thread for this. >> >>> - Basic macro support(prevent the user from editing macro >>> generated >>> html) >>> >> >> It looks like you'd be recoding what is currently existing in the >> wysiwyg editor. While this is nice to have it in word, I'm wondering >> what it's going to cost to maintain the 2 features. >> > I'm only referring to making macro generated content read-only. How will a user edit a macro? > IMO, > this is not nice to have, it's mandatory, as without it, the user will > damage every page that contains a macro. Yes sure. I was just thinking that you'll end up doing the same thing as the wysiwyg is doing but I don't see any way out if we want to have advanced features in Word. Right now it's macro but later on it'll be support for other Transformation changes which must also be read only, then you need to edit macros, etc. I think this is great from a user POV. I'm just realizing that XWord is going further than what I thought it would do initially. This is good. However it means we'll need to maintain/support it in the future and this means building an MS Office dev team. Right now you're the only one to know .Net and this code. So if we want to go ahead full steam on all features we need to think about how we spread your knowledge to others. I guess one first step is for you to document cleanly the architecture, how to build, how to deploy, dev environment to code, etc. > Marius: is this implemented on the server or on the client for the > WYSIWYG? If it's on the server then it would be great to reuse it for > XWord. :) > If not, then I see no other option then to do something similar > on .net. >> >>> - 1.0 RC1 - 1-2 weeks from M2 >>> - Bug fixing >>> - Stable and ergonomic UI >>> - Remove the sever package and rely only on XML-RPC >>> >> >> What is the "server package"? >> > > It's a collection of wiki pages that contain the services used by > XWord. > > In the absence of a fully featured and actual api, velocity + groovy > remains the most powerful way of extending or communicating with > xwiki. > See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/ ok, I see. >>> - 1.0 Final - 1-2 >>> - Rock solid UI >>> - Production quality html output and wiki syntax conversion. >>> >> >> If you succeed in using the server side version of html/wiki syntax >> conversion tools then you'll get rock solid stuff with no maintenance >> need on your side. >> >> WDYT? >> > The html/wiki syntax is already done at the server. Sorry, but I'll > give > a -1 for Word html cleaning on the server, at least at it's current > state. WDYM by "its current state"? If you can use the server side cleaning then I'd rather you use it. And if it's not good enough then we need your help/energy to improve it on the server rather than redevelop it in .Net since we also need it for copy/paste in the wysiwyg for example. Or are you talking about something else? Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
