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#HFirstversi…
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