Renewed XWord roadmap

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Renewed XWord roadmap

Florin Ciubotaru

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
    - 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
    - Export using filtered html - done
    - 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
    - Basic macro support(prevent the user from editing macro generated
html)
- 1.0 RC1 - 1-2 weeks from M2
    - Bug fixing
    - Stable and ergonomic UI
    - Remove the sever package and rely only on XML-RPC
- 1.0 Final - 1-2
    - Rock solid UI
    - Production quality html output and wiki syntax conversion.

Please tell me your opinion.
Thanks,
Florin
 




_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

lucaa
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
>     - 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
>     - Export using filtered html - done
>     - Export with non-filtered html - buggy
>     - Deployment and infrastructure - problematic because it uses ClickOnce.

quite a long M1.
You could also think about making it installable anyway (not necessarily through
a very nice and easy process -- but with a visible enough warning and
appropriate instructions) so that you finally have people using it anyway and
helping you on bug report / feature design.

> - 1.0 M2 - 2-3 weeks from M1
>     - Solve as many reported bugs
>     - Improve html filters
>     - Introduce the XML-RPC communication mode
>     - Basic macro support(prevent the user from editing macro generated
> html)
> - 1.0 RC1 - 1-2 weeks from M2
>     - Bug fixing
>     - Stable and ergonomic UI
>     - Remove the sever package and rely only on XML-RPC
> - 1.0 Final - 1-2
>     - Rock solid UI
>     - Production quality html output and wiki syntax conversion.
>
> Please tell me your opinion.
> Thanks,
> Florin
>  
>

+1,
sounds good.

Happy coding,
Anca

>
>
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

vmassol
Administrator
In reply to this post by Florin Ciubotaru
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?

>    - 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?

>    - 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).

>    - 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).

>    - 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.

> - 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"?

> - 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?

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Florin Ciubotaru
In reply to this post by lucaa
Hi Anca,

Anca Paula Luca wrote:

> 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
>>     - 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
>>     - Export using filtered html - done
>>     - Export with non-filtered html - buggy
>>     - Deployment and infrastructure - problematic because it uses ClickOnce.
>>    
>
> quite a long M1.
>  
> You could also think about making it installable anyway (not necessarily through
> a very nice and easy process -- but with a visible enough warning and
> appropriate instructions) so that you finally have people using it anyway and
> helping you on bug report / feature design.
>  
XWord is installable since December and it is available at:
http://incubator.myxwiki.org/xwiki/bin/view/XWord/
The problem is that the it's deployment is not compatible with the
common XWiki.org release process and infrastructure.

>  
>> - 1.0 M2 - 2-3 weeks from M1
>>     - Solve as many reported bugs
>>     - Improve html filters
>>     - Introduce the XML-RPC communication mode
>>     - Basic macro support(prevent the user from editing macro generated
>> html)
>> - 1.0 RC1 - 1-2 weeks from M2
>>     - Bug fixing
>>     - Stable and ergonomic UI
>>     - Remove the sever package and rely only on XML-RPC
>> - 1.0 Final - 1-2
>>     - Rock solid UI
>>     - Production quality html output and wiki syntax conversion.
>>
>> Please tell me your opinion.
>> Thanks,
>> Florin
>>  
>>
>>    
>
> +1,
> sounds good.
>
> Happy coding,
> Anca
>
>  
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>    
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>  

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Florin Ciubotaru
In reply to this post by vmassol
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.

>  
>>    - 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.
>
>  
>>    - 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.

>  
>>    - 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. IMO,
this is not nice to have, it's mandatory, as without it, the user will
damage every page that contains a macro.
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/

>> - 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.
> Thanks
> -Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Marius Dumitru Florea
Hi Florin,

Florin Ciubotaru wrote:
[snip]

>>>    - 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. IMO,
> this is not nice to have, it's mandatory, as without it, the user will
> damage every page that contains a macro.
> 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. :)

It's done on the client-side. At most you can try to use the same
technique I use, but I doubt it's going to work in Word. Let's talk
about this Monday.

Thanks,
Marius

> If not, then I see no other option then to do something similar on .net.
[snip]
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

vmassol
Administrator
In reply to this post by Florin Ciubotaru

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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Florin Ciubotaru
Vincent Massol wrote:

> 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.
>
>  
Yes, first I also thought that view/edit rights should do the trick. But
unfortunately, without macro support, edit right is too generic. For
example it's ok to have edit right on a current page in the XWiki space
end edit it in the wiki editor, but it's not ok to have edit rights and
edit it with the wysiwyg/Word. See what I mean?

>>>>   - 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?
>  
What do you mean? The user should not be able to edit the macro in Word.
What is wrong right now: The user is editing a wiki page with Word. This
page contains a macro, let's say, toc. All he sees in Word is a list
with links. When he will save the page to the wiki again, the toc will
be overridden by the bulleted list.

>  
>> 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.
>
>  
Yes, this should mostly go under xoffice.xwiki.org. Where do you think I
should put the .net/vsto coding conventions, building, etc. Is it under
dev.xwiki.org?

>> 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?
>  
By its' current state, I mean that it is only designed to work as an
import filter.
First: I need it to preserve embedded elements data.
Second: I have the ability to force Word to output a different/better
html then the one provided by copy/paste. I need the html cleaner to
work well with this kind of output.
Sure, I prefer to have a unified cleaner on the server. But there will
always be filters/adapters on the client(not necesarely cleaners). For
example:
The 'src' and 'href' attributes have different values on XWiki and on a
local html file used by Word. The user can open different edit sessions
on multiple pages. Each session has an assigned html converter that uses
filters for XWiki->Word and Word->XWiki conversion. Each converter has a
number of dictionaries assuring the consistency of these attributes and
the bijectivity of the operation. I prefer to have high cohesion on this
and distribute it as less as possible.
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>  

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Florin Ciubotaru
In reply to this post by Marius Dumitru Florea
Marius Dumitru Florea wrote:

> Hi Florin,
>
> Florin Ciubotaru wrote:
> [snip]
>  
>>>>    - 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. IMO,
>> this is not nice to have, it's mandatory, as without it, the user will
>> damage every page that contains a macro.
>> 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. :)
>>    
>
> It's done on the client-side. At most you can try to use the same
> technique I use, but I doubt it's going to work in Word. Let's talk
> about this Monday.
>
>  
OK, thanks.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>  

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Renewed XWord roadmap

Jerome Velociter
In reply to this post by Florin Ciubotaru
Hi,

Florin Ciubotaru wrote:

> Vincent Massol wrote:
>  
>> 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.
>>
>>  
>>    
> Yes, first I also thought that view/edit rights should do the trick. But
> unfortunately, without macro support, edit right is too generic. For
> example it's ok to have edit right on a current page in the XWiki space
> end edit it in the wiki editor, but it's not ok to have edit rights and
> edit it with the wysiwyg/Word. See what I mean?
>  
>>>>>   - 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?
>>  
>>    
> What do you mean? The user should not be able to edit the macro in Word.
> What is wrong right now: The user is editing a wiki page with Word. This
> page contains a macro, let's say, toc. All he sees in Word is a list
> with links. When he will save the page to the wiki again, the toc will
> be overridden by the bulleted list.
>  
>>  
>>    
>>> 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.
>>
>>  
>>    
> Yes, this should mostly go under xoffice.xwiki.org. Where do you think I
> should put the .net/vsto coding conventions, building, etc. Is it under
> dev.xwiki.org?
>  

For me, it can go under xoffice.xwiki.org, at least in a first step.

Jerome.

>>> 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?
>>  
>>    
> By its' current state, I mean that it is only designed to work as an
> import filter.
> First: I need it to preserve embedded elements data.
> Second: I have the ability to force Word to output a different/better
> html then the one provided by copy/paste. I need the html cleaner to
> work well with this kind of output.
> Sure, I prefer to have a unified cleaner on the server. But there will
> always be filters/adapters on the client(not necesarely cleaners). For
> example:
> The 'src' and 'href' attributes have different values on XWiki and on a
> local html file used by Word. The user can open different edit sessions
> on multiple pages. Each session has an assigned html converter that uses
> filters for XWiki->Word and Word->XWiki conversion. Each converter has a
> number of dictionaries assuring the consistency of these attributes and
> the bijectivity of the operation. I prefer to have high cohesion on this
> and distribute it as less as possible.
>  
>> Thanks
>> -Vincent
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>  
>>    
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>  

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs