On Feb 13, Sergiu Dumitriu wrote :

This is indeed a good idea. Can you make a jira task and attach the patch to it? http://jira.xwiki.org/

Hi Sergiu, I'm waiting for consensus on what to do concerning regex handling before opening the issue. Pablo

Hi Luis, On Tue, Feb 13, 2007 at 08:48:11PM +0100, Luis Arias wrote :

I find the experiments you are doing very interesting ! How far are you thinking of going here ?

Targetting XWiki for mobile devices is one of the objectives of the XWiki Concerto RNTL (french's ANR project) project, so I am not alone on this ;)

I mean it would be excellent to have an assessment of the issues involved because I believe we have little experience with that platform and maybe the effort is reasonable and would open the way to a much wider user base for concerto applications, probably really much wider given the volumes involved in that market. Jetty and velocity is really promising !

The J2ME configuration (CDC+FP) which I am considering is the rough equivalent of a JDK 1.3, with some new classes added but some classes missing too. [1] The VM for CDC configuration (cvm) is a complete implementation of the java VM, so the main problem here are the missing library classes. Yet modifying XWiki so it does not uses the missing classes is no small step. Regards, Pablo [1] http://java.sun.com/products/cdc/wp/cdc-whitepaper.pdf (page 14 contains the classes available in each profile).

On Feb 14, jeremi joslin wrote :

Hi Pablo, So you want to make xwiki core to be J2ME compatible?

For the time being I am just investigating the J2ME possibility. I currently see two general ways of having XWiki in a mobile device: * XWiki run on a server, the device uses a standard browser to interact. No need for J2ME, some changes (Skin, plugins, ...) will probably be necessary so that XWiki is nice to use in mobile. * Run XWiki or a stripped version of XWiki in the device. This gives us more possibilities: a disconnected mode, better exploiting the device features (camera, tactile screen, etc.) If we go for the second one, one possibility is J2ME, either by porting the entire XWiki core, or by reusing the needed XWiki parts to build a small XWiki version for mobiles. I think the component oriented architecture proposed by Vincent would greatly help to do this. Indeed we could build a XWiki for mobiles taking only the components we need, maybe replacing some of them by mobile friendly version while avoiding a fork from the standard XWiki. Anyways this project is only starting, so I am really interested in your ideas and opinions, Pablo

Thanks Pablo for the link to the whitepaper which is very clear ! How do you find the missing classes ? By trying to run XWiki standalone in that configuration ? Are there a lot of missing classes in the third party jars ? Sounds like it is painstaking work but certainly worth the effort ! Good luck to you, Luis On 2/14/07, Pablo Oliveira <[email protected]> wrote:

The J2ME configuration (CDC+FP) which I am considering is the rough equivalent of a JDK 1.3, with some new classes added but some classes missing too. [1]

The VM for CDC configuration (cvm) is a complete implementation of the java VM, so the main problem here are the missing library classes.

Yet modifying XWiki so it does not uses the missing classes is no small step.

Regards,

Pablo

[1] http://java.sun.com/products/cdc/wp/cdc-whitepaper.pdf (page 14 contains the classes available in each profile).

-- Luis Arias http://www.xwiki.com +33 6 14 20 87 93 skype : kaaloo

On Feb 13, Vincent Massol wrote :

I really don't think we should use ORO at all, now that Regexp is included in the JDK (since 1.4). We should really get rid of ORO.

If you have decided that the minimum requirements for XWiki are 1.4, then it probably makes sense to keep only java.util.regex. In this case there are quite a few places in XWiki where we should replace ORO by util.regex. And some places where we should optimize the regex handling: for example this code in XWikiDocument.java: String htmlregexp = "</?(html|body|img|a|i|b|embed|script|form| [...]; try { Util util = new Util(); List list = util.getMatches(content2, htmlregexp, 1); if (list.size() > 0) { return true; } } catch (MalformedPatternException e) { } return false; is really inneficient since we construct a list with all the html matches in the document when a single match would have accomplished the desired result.

I think it's going to be hard not to use any 1.4 features, especially as XWiki is based on 1.4 right now. We've already decided to stay 1.4 compatible. I don't think we can decide to stay 1.3 compatible...

Sure, i'm not asking for 1.3 compatibility ;) I was just trying to evaluate how hard it would be porting some parts to CDE so we can build a lighter version. I agree with Ludovic in that technology evolves fast and we should try to anticipate it. That's why I think 1.4 (and at a point 1.5) features will surely make they way into some J2ME future specs. I believe that j2me will need to keep the pace with j2se api or it.

As Ludovic was saying, if we plan ahead, all mobiles devices will have a JDK 1.4 compliance level in not too long...

Sure. Well I was justing toying with the J2ME possibility (which manages to run some impressive applications like Jetty 6 and some of the Velocity examples in my preliminaries tests). Yet you realize that if our policy is wait for more memory in mobiles, and wait for a decent 1.4 SE JDK in mobiles, there is not much work to do on porting XWiki on mobiles (and there is a lot of work to make mobiles faster ;). In that case I will refocus on user interface and useability concerns in the mobility context...

Note sure how this will help you though Pablo. We need to find a solution. Has anyone researched if there's a java.util.regexp implementation for 1.3?

I searched for a java.util.regexp for j2me and did not found one, it appears to be the same for 1.3. Regards, Pablo