Count me in on this project... if I can find the time.
One thing to note with phones is that its a mixed list.
All NEC phones, Toshiba Phones, Panasonic phones
(regardless of DoCoMo, JPhone or TuKa) have certain
quirks in common.
In addition restricting ourselves to DoCoMo, the SO
phones, D Phones, P Phones of whatever series have certain
big similarities.
Now also, the 503, 210 ,211 series have a different set of similarities.
So in effect we have 4 superclasses.... Manufacturer (P D F SH ER...) Series: (FOMA 503 210
501....)
and Provider: (AU, TuKa, JPhone, DoCoMo), and also we have
another clincher, browser; (EZWeb JPhone and DoCoMo)
They all are relevant!
These things aren't in synch with each other. And this excludes Korea, Taiwan
and Europe (US is still to far behind to worry about).
Christian Molstrom wrote:
> On advantage of the inheritance thing is dealing with an
> device that is unknown to the database. In such cases you
> can:
>
> 1. return no data
> 2. return the best fit
>
> 1 is not very useful from service point of view, if that is
> what the aim is. 2 is great because it means that you will
> at least get information about the device that will
> (probably) guarantee playable or viewable media.
>
> Suppose DoCoMo comes out with a new 212 series. 10 phones
> are planned, but like always they come out a staggard times
> over the course of a year. With the inheritance thing you
> can have a generic 212 device that will contain profile data
> not only common to all the 212s but more importantly, data
> that is the least common denominator of all the phones.
>
> In practice would this be THAT useful if developers are
> diligent in maintaining the data set? Maybe not. However,
> the idea of a system that can deal in some way with an
> unknown device is appealing.
>
> Christian
>
> ----- Original Message -----
> From: "Curt Sampson" <cjs@cynic.net>
> To: <keitai-l@appelsiini.net>
> Sent: Wednesday, February 27, 2002 1:40 AM
> Subject: (keitai-l) Re: open source keitai tools (was Re:
> Re: western phone, imode si
>
> >
> >
> > Well, here's my take on the data inheritance thing: in
> most cases,
> > why bother?
> >
> > A lot of this stuff is just whacking in data from spec
> sheets. Do
> > I really want to sit down and figure out what my F503i
> shares in
> > common with other 503i models, and which particular thing
> it should
> > inherit from, and so on? Or do I just want to look at the
> spec.
> > sheet and type in "screen width = 130 pixels" and "screen
> height
> > = 160 pixels"? The latter is faster to create, and also
> easier to
> > read and debug (because I don't have to go looking in
> another place
> > to see what's being inherited).
> >
> > There might be certain situations where inheritance could
> help.
> > Say we have eighteen different pieces of data for a sound
> chip,
> > and we know that all phones that use that sound chip work
> exactly
> > the same in that respect (this is a big supposition). In
> that case
> > it might be useful to say, "sound chip = yamaha foo". But
> I'd want
> > to verify that that's actually the case before going to
> the effort
> > of doing that work. If and when we start to see large
> chunks of
> > common data, we can refactor to consolidate that.
> >
> > Keep in mind that inheritence is useful because it works
> *both*
> > ways; you can change the behaviour of all your children by
> changing
> > the parent. But it doesn't seem so likely to me that we'd
> ever want
> > to do that; why on earth would I ever want to change the
> screen
> > size of an entire group of phones?
> >
> > As for Christian's thought about using a format easier to
> edit than
> > than XML: I'm open to that. If we're not getting an extra
> boost
> > from XML that makes up for the difficulty, why use it? In
> fact, we
> > might just as well do the initial implementation with
> Java-style
> > properties files, and move to XML only when we figure out
> how that
> > doesn't work for us.
> >
> > cjs
> > --
> > Curt Sampson <cjs@cynic.net> +81 90 7737 2974
> http://www.netbsd.org
> > Don't you know, in this new Dark Age, we're all
> ight. --XTC
> >
> >
> > This mail was sent to address cmolstrom@lightsurf.com
> > Need archives? How to unsubscribe?
> http://www.appelsiini.net/keitai-l/
> >
> >
>
> This mail was sent to address paul.lester@lincmedia.co.jp
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
--
*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=
Paul Bryan Lester
Layer-8 Technologies Inc
LincMEDIA Group
QA ENGINEER/Programmer etc etc
EMAIL: paul.lester@L8tech.com
paul_lester@lincmedia.co.jp
--
http://myc.thetamusic.com/framesets/myc.html
http://www.thetamusic.com/
http://www.lincmedia.co.jp/
http://www.chakumatic.com/
http://www.daijob.com/
personal homepage: http://pbl1.tripod.com/
personal EMAIL: pbl1@cornell.edu
*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=
Received on Wed Feb 27 05:44:39 2002