Hi everyone, I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix. Here's my first take below. Please comment on it and add other stuff. This is a brainstorming session. Then we can start assigning committers/contributors to goals/issues. General Goals: ============ * Bug fixes ** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date * Better performance ** Run XE with a profiler and find bottlenecks ** Reduce number of database calls ** Improved page loading (JV) ** Make Stats usable on xwiki.org (ThomasM) * More automated tests ** More selenium tests ** Add tests on Tomcat 6.x as part of the CI build ** Add tests on Windows and with IE6 and IE7 as part of the CI build * No new features in general Of course there are some goals that are always valid irrelevant on any release and that we should keep in mind: * More tests * Better javadoc * More documentation on xwiki.org * Code cleanup/refactoring * Extract more plugins from core into plugins proper Specific issues to implement/fix ======================== * Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99 ) * (optional - depending on availability) - New rendering rewrite (http://jira.xwiki.org/jira/browse/XWIKI-654 ) * (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions ) * Add any other critical issue here Thanks -Vincent
On Mon, Mar 10, 2008 at 3:10 PM, Vincent Massol <[email protected]> wrote:
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix.
Here's my first take below. Please comment on it and add other stuff. This is a brainstorming session. Then we can start assigning committers/contributors to goals/issues.
General Goals: ============
* Bug fixes ** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date
* Better performance ** Run XE with a profiler and find bottlenecks ** Reduce number of database calls ** Improved page loading (JV) ** Make Stats usable on xwiki.org (ThomasM)
* More automated tests ** More selenium tests ** Add tests on Tomcat 6.x as part of the CI build ** Add tests on Windows and with IE6 and IE7 as part of the CI build
* No new features in general
Of course there are some goals that are always valid irrelevant on any release and that we should keep in mind: * More tests * Better javadoc * More documentation on xwiki.org * Code cleanup/refactoring * Extract more plugins from core into plugins proper
Specific issues to implement/fix ========================
* Add support for removing class properties ( http://jira.xwiki.org/jira/browse/XWIKI-99 ) * (optional - depending on availability) - New rendering rewrite ( http://jira.xwiki.org/jira/browse/XWIKI-654 ) * (optional - depending on availability) - Interface extensions ( http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions ) * Add any other critical issue here
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
XEM will need in the core for its next release: - http://jira.xwiki.org/jira/browse/XWIKI-1966 : I take care of this, I almost finished. Not very big, just wanted to list what I think of. It's all I see now. -- Thomas Mortagne
Vincent Massol writes:
I'd like everyone's input for defining the XE 1.4 roadmap both on the
general objectives and specific features/bugs to implement/fix.
Specific issues to implement/fix ================================ WYSIWYG editor stability - Table behavior (a new table editor would be welcome) - Whitespace processing - Misbehavior in the presence of code or complex styles Attachment handling - memory / resource demands - proper versioning (if 2 different users upload the same document name) Wishlist ======== - Table of contents macro a la mediawiki - WebDAV would be nice... We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now. -- Jim Dowson CTO, Global Services, EMC Corporation Linx: (617) 598-0505
Hi Jim, Thanks for the feedback. See below. On Mar 10, 2008, at 8:24 PM, [email protected] wrote:
Vincent Massol writes:
I'd like everyone's input for defining the XE 1.4 roadmap both on the
general objectives and specific features/bugs to implement/fix.
Specific issues to implement/fix ================================
WYSIWYG editor stability - Table behavior (a new table editor would be welcome) - Whitespace processing - Misbehavior in the presence of code or complex styles
Attachment handling - memory / resource demands - proper versioning (if 2 different users upload the same document name)
What's not working with versioning of attachments? I don't recall seeing a problem about this.
Wishlist ======== - Table of contents macro a la mediawiki
Already exists (unless the mediawiki one does something we don't). See http://code.xwiki.org/xwiki/bin/view/Macros/TocMacro
- WebDAV would be nice...
Yep. We're planning to do that one as part of the Google Summer of Code so that's probably going to be more for XE 1.5 or later.
We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now.
Very cool! Thanks -Vincent
Vincent Massol writes:
- proper versioning (if 2 different users upload the same document name)
What's not working with versioning of attachments? I don't recall seeing a problem about this.
It might only be under 1.2 - but if someone downloads an attachment created by a different user, updates it & then uploads the file under the same name, it does not appear as a version of the prior document - it's a new document. To get around this we had to have folks doing updates to authenticate under the same username (for one particular document).
Wishlist ======== - Table of contents macro a la mediawiki
Already exists (unless the mediawiki one does something we don't). See
Yes, but No :-) I mean with the same show/wide-in-a-box functionality. When creating large pages, this becomes very important - and the toc macro needs a nice wrapper around it ... like mediawiki has ;-)
- WebDAV would be nice...
Yep. We're planning to do that one as part of the Google Summer of Code so that's probably going to be more for XE 1.5 or later.
It can definitely wait until 1.5 or later - I was only wishing.
We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now.
Very cool!
How should we best do this? Show the code here (or devs)? The last time I played with xwiki.org, I got slapped :-) (and rightfully so!)
On Tue, Mar 11, 2008 at 9:29 PM, <[email protected]> wrote:
Vincent Massol writes:
- proper versioning (if 2 different users upload the same
document name)
What's not working with versioning of attachments? I don't recall seeing a problem about this.
It might only be under 1.2 - but if someone downloads an attachment created by a different user, updates it & then uploads the file under the same name, it does not appear as a version of the prior document - it's a new document.
To get around this we had to have folks doing updates to authenticate under the same username (for one particular document).
FWIW I'm not able to reproduce it with 1.4M1 [1]. [1] : http://img206.imageshack.us/my.php?image=multipleauthorattachja4.png JV.
Jean-Vincent Drean wrote:
On Tue, Mar 11, 2008 at 9:29 PM, <[email protected]> wrote:
Vincent Massol writes:
- proper versioning (if 2 different users upload the same
document name)
What's not working with versioning of attachments? I don't recall seeing a problem about this.
It might only be under 1.2 - but if someone downloads an attachment created by a different user, updates it & then uploads the file under the same name, it does not appear as a version of the prior document - it's a new document.
To get around this we had to have folks doing updates to authenticate under the same username (for one particular document).
FWIW I'm not able to reproduce it with 1.4M1 [1].
[1] : http://img206.imageshack.us/my.php?image=multipleauthorattachja4.png
I am not able to reproduce it with 1.2.0 or 1.2.2, and as far as I know nobody ever reported a similar problem, and there never were any code that considered the user name when uploading files. Also, if the files have the same name, it is impossible to store them separately, as they are put in a table indexed (unique key constraint) by a hash function on the attachment + wiki document name. -- Sergiu Dumitriu http://purl.org/net/sergiu/
[email protected] wrote:
We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now.
Very cool!
How should we best do this? Show the code here (or devs)?
When you have something shareable, better put it somewhere on your servers, or on public hosting, and send a link to the devs or users list. After that, we'll see. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mar 13, 2008, at 3:41 AM, Sergiu Dumitriu wrote:
[email protected] wrote:
We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now.
Very cool!
How should we best do this? Show the code here (or devs)?
When you have something shareable, better put it somewhere on your servers, or on public hosting, and send a link to the devs or users list. After that, we'll see.
We'll have three solutions after that: 1) Put it on the code zone 2) Put it in the "xlet" SVN that we want to create to people wanting a place to store their xwiki-related projects 3) Integrate it in the Core/Platform Thanks -Vincent
[email protected] wrote:
Specific issues to implement/fix ================================
WYSIWYG editor stability - Table behavior (a new table editor would be welcome) - Whitespace processing - Misbehavior in the presence of code or complex styles
Thanks for the WYSIWYG wishlist. We'll take all this into account with the new editor. We believe that by using GWT we can build an editor that is much more stable and capable of advanced stuff usefull in the wiki. This will be possible especially thanks to unit testing since the GWT code is java compiled to JS. GWT also gives us the possiblity to have browser specific implementation of some of the code which allows to not polute the JS code with browser specific stuff when it's not necessary. Furthermore we will built real-time editing (multiple persons editing the same page) in the editor. We already have a prototype working of this.
Attachment handling - memory / resource demands - proper versioning (if 2 different users upload the same document name)
Wishlist ======== - Table of contents macro a la mediawiki
There is {toc}. It might just be a style issue to make it like mediawiki.
- WebDAV would be nice...
We also have a prototype of this, though it doesn't currently make it in our priority list. We have proposed it for the Google Summer of Code. If any student is interested it's a fun project.
We're looking to contribute the notion of a simple reputation engine (user and content rating) that we have in prototype now.
Great ! We want it ! Ludovic
-- Jim Dowson CTO, Global Services, EMC Corporation Linx: (617) 598-0505
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Mon, Mar 10, 2008 at 3:10 PM, Vincent Massol <[email protected]> wrote:
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix.
* No new features in general
I'd like to commit a first implementation of keyboard shortcuts in xwiki : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiKeyboardShortcuts
* Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99)
Cool!
* (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions)
Wow, it would be awesome to have it in 1.4, what's the status on this ? JV.
On Mar 11, 2008, at 6:34 PM, Jean-Vincent Drean wrote:
On Mon, Mar 10, 2008 at 3:10 PM, Vincent Massol <[email protected]> wrote:
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix.
* No new features in general
I'd like to commit a first implementation of keyboard shortcuts in xwiki : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiKeyboardShortcuts
+1
* Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99 )
Cool!
* (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions )
Wow, it would be awesome to have it in 1.4, what's the status on this ?
Marta and Sergiu are working on this AFAIK. Any ETA Marta/Sergiu? Thanks -Vincent
Vincent Massol wrote:
On Mar 11, 2008, at 6:34 PM, Jean-Vincent Drean wrote:
On Mon, Mar 10, 2008 at 3:10 PM, Vincent Massol <[email protected]> wrote:
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix.
* No new features in general
I'd like to commit a first implementation of keyboard shortcuts in xwiki : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiKeyboardShortcuts
+1
* Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99 )
Cool!
* (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions )
Wow, it would be awesome to have it in 1.4, what's the status on this ?
Marta and Sergiu are working on this AFAIK. Any ETA Marta/Sergiu?
Not on this, we're working on SkinExtensions, which is much simpler to implement. The code is mostly done, with the following problems: - We're still trying to decide if YUICompressor is the best choice. It seems to be a good choice when comparing features and functionality, but on the inside it is UGLY! It looks like some quick and dirty C code, although it is at version 2.3.5 (they just removed System.exit as a failure mechanism in 2.3.0!). Unfortunately there is nothing else that does variable minimization, so the choice is whether we use YUICompressor or use something with less compression. - We're still trying to find a place where to do the hook replacement. At first Plugin#endRendering looked like a good option, but it seems that it is not called when parsing templates, so the choice is between writing some custom code in the parse method, or make the plugins also be called for that parsing process, or to call the RenderingEngine#interpret method instead of the current shortcut, which is to call directly VelocityRenderingEngine. So, if we find some time to address these points, we'll have it ready for usage this weekend. I think that I'll have to review the whole parsing/rendering process and fix all those Programming Rights leaks on the way, too, as this is needed for Template Extensions (draft proposal sitting on my computer). As for Interface Extensions, I'll have to modify the proposal to include some of the observations Vincent made, then I'll start working on it. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Jean-Vincent Drean wrote:
I'd like to commit a first implementation of keyboard shortcuts in xwiki : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiKeyboardShortcuts
Are the shortcuts localizable? This can be done by parsing the javascript and using $msg.get("core.shortucts.save"), for example. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Tue, Mar 11, 2008 at 7:05 PM, Sergiu Dumitriu <[email protected]> wrote:
Jean-Vincent Drean wrote:
I'd like to commit a first implementation of keyboard shortcuts in xwiki : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiKeyboardShortcuts
Are the shortcuts localizable? This can be done by parsing the javascript and using $msg.get("core.shortucts.save"), for example.
They were not, thanks for the recommendation, I've put the shortcuts in the application resources under core.shortcuts.*. I've commited the feature, suggestions and comments are welcome (see also http://platform.xwiki.org/xwiki/bin/view/Features/KeyboardShortcuts). JV.
Hi everyone,
I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix.
Here's my first take below. Please comment on it and add other stuff. This is a brainstorming session. Then we can start assigning committers/contributors to goals/issues.
General Goals: ============
* Bug fixes ** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date
* Better performance ** Run XE with a profiler and find bottlenecks ** Reduce number of database calls ** Improved page loading (JV) ** Make Stats usable on xwiki.org (ThomasM)
* More automated tests ** More selenium tests ** Add tests on Tomcat 6.x as part of the CI build ** Add tests on Windows and with IE6 and IE7 as part of the CI build
* No new features in general
Of course there are some goals that are always valid irrelevant on any release and that we should keep in mind: * More tests * Better javadoc * More documentation on xwiki.org * Code cleanup/refactoring * Extract more plugins from core into plugins proper
Specific issues to implement/fix ========================
* Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99 ) * (optional - depending on availability) - New rendering rewrite (http://jira.xwiki.org/jira/browse/XWIKI-654 ) * (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions ) * Add any other critical issue here
It is not a critical issue, but we should also plan the platform-web-gwt api upgrade to gwt 1.4.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
ancapaula.luca＠xwiki.com -
Dowson_Jim＠emc.com -
Jean-Vincent Drean -
Ludovic Dubost -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol