[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tdf-discuss] java / phone strategy ..


On Wed, 2010-11-03 at 09:09 -0400, Michael Meeks wrote:
> Hi Ian,
>
> On Wed, 2010-11-03 at 12:50 +0000, Ian wrote:
> > Ok, perhaps a daft suggestion but the principle is that all cell phones
> > will have a vast amount of RAM and fast CPUs in the next 2 to 3 years. A
> > gig of RAM is normal now, it would have been unthinkable 10 years ago.
>
> Sure - but our existing performance problems will get no better by
> re-writing in Java :-) I think native code is the best approach.

Oh I agree, I was partly just provoking the debate. I used to write
stuff in ARM Assembler but probably that is a bit extreme and that was
20 years ago in the days of ARM 2 and ARM 3 ;-)

> > > I've seen OO.o running quite nicely on small ARM devices as native
> > > code; that would be my approach to mobile.
> >
> > So why is there no strategy to get OOo on to these mobile devices? Or
> > maybe there is ?
>
> Sure - improve performance and memory footprint - that work is
> underway, and beef up the ARM port. Beyond that - a new UI shell is
> required on top - and we have a mobile phone version.

That sounds good.

> Ultimately - the techincal strategy is easy; the only problem is people
> to actually hack on doing it :-) are you volunteering ?

What will be much more effective is for me to devise a strategy that can
pay several developers to work on the project. I'm out of date in
hacking, but I know how we should be able to make money. I think that is
just a better use of the resources I can provide.

> if so, we can
> certainly help out with code pointers, review, encouragement, community
> building etc.
>
> All the best :-)
>
> Michael.

--
Ian
Ofqual Accredited IT Qualifications
A new approach to assessment for learning
www.theINGOTs.org - 01827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.


--
Unsubscribe instructions: Email to discuss+help@documentfoundation.org
Posting guidelines: http://netmeister.org/news/learn2quote.html
Archive: http://www.documentfoundation.org/lists/discuss/
*** All posts to this list are publicly archived ***

Follow-Ups:
Re: [tdf-discuss] java / phone strategy ..Benjamin Horst <bhorst@mac.com>
References:
[tdf-discuss] Java dependency"T. J. Brumfield" <enderandrew@gmail.com>
Re: [tdf-discuss] Java dependencyjonathon <toki.kantoor@gmail.com>
Re: [tdf-discuss] Java dependencyJohannes Bausch <johannes.bausch@gmail.com>
Re: [tdf-discuss] Java dependencyFrank Esposito <frankesposito@gmail.com>
[tdf-discuss] Re: Java dependencyMarc Paré <marc@marcpare.com>
Re: [tdf-discuss] Re: Java dependency"Mirek M." <mazelm@gmail.com>
Re: [tdf-discuss] Re: Java dependency"T. J. Brumfield" <enderandrew@gmail.com>
Re: [tdf-discuss] Re: Java dependencyCedric Bosdonnat <cedric.bosdonnat.ooo@free.fr>
Re: [tdf-discuss] Re: Java dependencyChristian Lohmaier <lohmaier+ooofuture@googlemail.com>
Re: [tdf-discuss] Re: Java dependencySebastian Spaeth <Sebastian@SSpaeth.de>
Re: [tdf-discuss] Re: Java dependencyIan <ian.lynch@theingots.org>
Re: [tdf-discuss] Re: Java dependencyMichael Meeks <michael.meeks@novell.com>
Re: [tdf-discuss] Re: Java dependencyIan <ian.lynch@theingots.org>
[tdf-discuss] java / phone strategy ..Michael Meeks <michael.meeks@novell.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the GNU Lesser General Public License (LGPLv3). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.