(keitai-l) Re: open source keitai tools (was Re: Re: western phone, imode si

From: Christian Molstrom <cmolstrom_at_lightsurf.com>
Date: 02/27/02
Message-ID: <003701c1bf38$2d00de70$6601a8c0@office.lightsurf.com>
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/
>
>
Received on Wed Feb 27 04:46:27 2002