Alex Blewitt wrote: > Converters are needed as an on demand basis - is there any reason the > dynamic loading of a charset could be augmented with the ability to > download additional converters if not found locally?
Now y'a getting fancy <g> but "yes" it is possible. In fact, you could generalize that to arbitrary areas of functionality. > This might not make sense for non-connected devices but for desktops > could allow a minimal set to be distributed and then others to be > acquired on demand. "Put floppy in drive A:" > Sent from my (new) iPhone Sent from my (old) laptop Regards, Tim - with apologies for being flippant :-) > On 18 Sep 2008, at 14:10, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> In another thread [1], Chris wrote: >>> Hi Tim, >>> >>>>> Sounds good to me. Let's see if anyone else is interested. >>> >>> Should we start a separate thread with a more obvious title? >> >> Done, tweak the subject as you see fit. >> >>>>> You spurred me into committing the patch I was sat on to reduce the >>>>> footprint of the NIO character converters, by making the native >>>>> implementations optional. You can now delete the 1.5Mb hyniochar >>>>> library and we'll fall back to doing the conversions in Java code. >>>>> >>>>> I'm sure there are more examples like this where we can have the >>>>> best of >>>>> both worlds for 'big' server and 'small' embedded sets of libraries. >>> >>> In fact JavaME CDC/FP doesn't include java.nio, with the result that I >>> regularly have to patch code that is using java.nio just to do simple >>> byte<->char conversions. >> >> True, as you are adhering to the ME specs. But if you are prepared to >> branch out and define an alternative reduced footprint library profile >> you might also choose to include NIO functionality, and 1.5 syntax >> support, etc. >> >> You may have some insights based on the "Mika class libraries with >> packages taken from Harmony" use cases you have already seen. >> >>> But in other respects this is a good example - for a >>> large class of applications (those which make only incidental use of >>> char >>> conversion) the java-only library is perfectly adequate and saves 1.5 MB >>> (handy if your platform only has 8 MB of ROM!). >> >> Exactly. Indeed, there are a number of charconv classes that we might >> decide are not of sufficient general interest to include in the small >> footprint definition. >> >> Today, the SE char converters are split into 'regular' and 'additional' >> packages. I'm not convinced about how much thought went into that >> classification, but by packaging them separately we could easily reduce >> the set to a core of converters, with the option to download and add in >> more as you need them. >> >>> Another area I would like to look at is Locale - last time I looked >>> Harmony's >>> Calendar was relying on a 6 MB library to handle Locale-related >>> stuff, it >>> could be interesting to have a lightweight alternative. >> >> Yes. I think we can do better with the set we have got, plus like the >> converters, we could have a reduced core set for those apps that don't >> deal with esoteric Locales. >> >> In such cases, I would first like to try and define a solution that >> starts small and grows to full SE, rather than define a separate code >> stream approach. >> >> [1] http://markmail.org/message/x3ydeos244pqpcws >> >> Regards, >> Tim >
