[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] RE: Committer nomination for Tom Schindl
|
The answer to how small depends on your target. I think mobile
frameworks get wider use as their footprint get smaller.
If your target is just the high end phones like E90 which has 128MB
RAM and 330Mhz ARM cpu then a bit less than 300K that EMF 1.x had is
reasonable. Unfortunately high end phones are not that big portion of
the market and do not create a big adoption. The adoption comes with
the feature phone segment which typically has less than 64MB RAM.
Currently, eRCP is not able to match to that market, although there is
an effort to improve it is not yet there. eSWT is a different story
where it exists on both segments today. On the other hand the specs
for the both segments are improving every year.
If I consider all factors, in-memory footprint, performance and size
on disk. Size on disk affects the distribution costs and is becoming
less important(especially if distributed with the phone). In my
experience in-memory footprint has been more an issue then performance
in eclipse technologies.
--
Gorkem
On Sat, Apr 5, 2008 at 10:32 PM, Ed Merks <merks@xxxxxxxxxx> wrote:
> Gorkem,
>
> How small would you figure would be small enough? For example, what would
> you consider to be a rough representative size for small, medium, large and
> just a bit too large for a complete application? How do jar size and
> in-memory footprint relate?
>
> The myriad of small efficient specialized list classes could all be
> emulated by a single less efficient implementation; the overhead of even
> the smallest class is quite large from what I remember. As a factual
> demonstration of what's possible, just look back at EMF 1.x. The jars was
> tiny:
>
> 90,830 Mar 26 2003 ./plugins/org.eclipse.emf.common_1.0.2
> /runtime/common.jar
> 221,479 Mar 26 2003 ./plugins/org.eclipse.emf.ecore_1.0.2
> /runtime/ecore.jar
>
> That's obviously excluding a great many of the things we have today, such
> as a package for all the XML Schema types along with the extended metadata
> support for them as well things like feature maps, EMaps. So it's clear
> that a drastically stripped down runtime is possible...
>
> I've got that cool Nokia E90; I sure wish I had time to get an EMF-based
> application running on it!
>
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
>
>
>
> "Gorkem Ercan"
> <gercan@xxxxxxx>
> Sent by: To
> eclipse-incubator "E4 developer list"
> -e4-dev-bounces@e <eclipse-incubator-e4-dev@eclipse.o
> clipse.org rg>
> cc
>
> 04/05/2008 02:49 Subject
> PM Re: [eclipse-incubator-e4-dev] RE:
>
>
> Committer nomination for Tom
> Schindl
> Please respond to
> E4 developer list
> <eclipse-incubato
> r-e4-dev@eclipse.
> org>
>
>
>
>
>
>
> Hey Ed,
> The EMF runtime for devices is a fantastic idea. I do not think
> Foundation 1.1 compatible EMF would be enough though. The ultra-weight
> EMF has a better chance on devices.
> --
> Gorkem
>
> On Sat, Apr 5, 2008 at 7:46 PM, Ed Merks <merks@xxxxxxxxxx> wrote:
> > Boris,
> >
> > I'd like to be an e4 committer too! To begin with, I'd like to help
> with
> > this new model exploration work. I can imagine all kinds of things we
> > might want to bring to the platform that relate to modeling. For
> example,
> > I've already been prototyping things like EMF for eRCP and RAP. I could
> > imagine that we might want to take the work I've done with EMF 2.2 to
> > enable eRCP/Foundation 1.1 and perhaps work towards an ultra light
> weight
> > (pruned-down) version of the EMF 2.2 runtime that would still be binary
> > compatible with the Java 5.0-exploiting version of the evolving 2.x
> stream.
> > I'd like to explore all the cool things that are possible when you bring
> > data binding and data modeling together. I'm just full of ideas, but
> I'd
> > better turn the fire hose off... Do I need to mention that I have a
> proven
> > track record? :-P
> >
> >
> > Ed Merks/Toronto/IBM@IBMCA
> > mailto: merks@xxxxxxxxxx
> > 905-413-3265 (t/l 313)
> >
> >
> >
> >
> >
> > Boris
> > Bokowski/Ottawa/I
> > BM@IBMCA
> To
> > Sent by: E4 developer list
> > eclipse-incubator
> <eclipse-incubator-e4-dev@eclipse.o
> > -e4-dev-bounces@e rg>
> > clipse.org
> cc
> >
> >
> Subject
> > 04/05/2008 12:24 [eclipse-incubator-e4-dev] RE:
> > PM Committer nomination for Tom
> > Schindl
> >
> > Please respond to
> > E4 developer list
> > <eclipse-incubato
> > r-e4-dev@eclipse.
> > org>
> >
> >
> >
> >
> >
> >
> > Just in case this could be misunderstood - if others are interested in
> > working with us on e4, I would also nominate them as committers in the
> same
> > way that I nominated Tom. Being a committer on the Platform project is
> not
> > a prerequisite. ;-)
> >
> > Writing to the mailing list about what you would like to do *is* a
> > prerequisite, though.
> >
> > Boris
> >
> > eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/05/2008
> 11:09:07
> > AM:
> >
> > > Kevin wrote:
> > > > At the risk of killing momentum, I'd like to suggest that this
> > > > investigation would work best if someone on the platform team (yes,
> > > > I'm looking at you Eric <g>) were involved to whatever degree it
> > > > made sense.
> > >
> > > I am a little surprised - Kevin did you realize that Tom is *already*
> a
> > > member of the Platform team, as a Platform UI committer?
> > >
> > > Yes, Eric should be involved in this, but I also think that Tom should
> be
> > > allowed to do the same thing Eric has done - produce some experimental
> > code
> > > to be used in the discussion (code speaks!) - and I have therefore
> > > nominated Tom as an e4 committer.
> > >
> > > For higher-bandwidth communication, we can use the #eclipse-dev
> channel
> > > (see http://wiki.eclipse.org/IRC). I know that both Eric and Tom can
> be
> > > found there regularly. Please remember to post occasional updates to
> the
> > > mailing list as well...
> > >
> > > Boris
> > >
> > > _______________________________________________
> > > eclipse-incubator-e4-dev mailing list
> > > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
