Maybe the problem here is in thinking of devices in terms of an inheritance
hierarchy?
An alternate way would be to compose the descriptions of a number of
different but related entities:
<provider name="DoCoMo">
yadda yadda
</provider>
<maker name="NEC">
yadda yadda
</maker>
<device name="N503i"
maker="NEC"
provider="DoCoMo">
...
</device>
Something like this is more readable, I think, than any kind of nested
scheme, XML or no.
It might be appropriate to have devices belonging to device families, and
then have the device family be able to specify (by name, or directly inline)
what the generic or default device should be for that family. This would
make it relatively straightforward to provide fallback behaviors.
A lot of this stuff is actually in the CCPP spec, although I think that
maybe (definitely?) it's more complicated than it needs to be.
Something simple would be a better way to start, I think.
Brian Takashi Hooper
Jiqoo, Inc.
----- Original Message -----
From: "Michael Turner" <leap@gol.com>
To: <keitai-l@appelsiini.net>
Sent: Wednesday, February 27, 2002 1:09 PM
Subject: (keitai-l) Re: open source keitai tools (was Re: Re: western phone,
imode si
>
>
> From: "Paul Lester" <paul_lester@lincmedia.co.jp>
>
> > 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.
>
> Presumably because they use the same chips or
> families thereof. I.e., what we've been call a 'mobile
> device' is better thought of 'a package of mobile devices.'
> Including 'browser' as a 'device.'
>
>
> > 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!
>
> Four superclasses in a multiple-inheritance OO framework.
> Oh boy.
>
> As a first cut, then, it seems you'd want default characterization
> for each of these, subclassing for quirks, bugs and features.
>
> In a relational framework, this is four tables to join, with a fair
> amount of redundancy in each table to make up for the
> lack of inheritance. And a fifth table where rows represent
> actual handsets. Breaking it up that way might make it
> more manageable.
>
> > 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).
>
> Thank god for small favors.
>
> -michael turner
> leap@gol.com
>
>
> > 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
> > >
> [snip]
>
>
> This mail was sent to address brian@jiqoo.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
>
>
Received on Wed Feb 27 08:36:26 2002