You can subscribe to this list here.
2002 |
Jan
|
Feb
(1) |
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Sam J. <ga...@yh...> - 2003-08-20 10:22:53
|
I'd like to see all this data available in xml format: http://www.nttdocomo.co.jp/p_s/imode/spec/info.html i.e. Jar size, Scratchpad size, panel and canvas screen sizes, heap size and default font. plus the User Agent would be nice. CHEERS> SAM kei...@li... wrote: > On Monday, August 18, 2003, at 08:44 PM, to...@no... wrote: > >>> page size (cache size) >>> page width text >>> horiz width >>> vertical width >>> color or greyscale or b/w >>> image formats >>> markup >> >> > *must have* page height (rows of text) *possibly useful...* colour > depth (8/16bit) autobreak English text (do any of the AU handsets do > this?) download speed (9.6, 28.8, 3G) java version other java info? > soundchip voices encoding (shift JIS, whatever the European ones use) > uin support. max email size (256 or 512 chars - useful if their > actions generate an email to themselves) --__--__-- |
From: Nick M. <ni...@ky...> - 2003-08-18 12:40:10
|
On Monday, August 18, 2003, at 08:44 PM, to...@no... wrote: > page size (cache size) > page width text > horiz width > vertical width > color or greyscale or b/w > image formats > markup *must have* page height (rows of text) *possibly useful...* colour depth (8/16bit) autobreak English text (do any of the AU handsets do this?) download speed (9.6, 28.8, 3G) java version other java info? soundchip voices encoding (shift JIS, whatever the European ones use) uin support. max email size (256 or 512 chars - useful if their actions generate an email to themselves) |
From: Thomas O'D. <to...@no...> - 2003-08-18 12:00:41
|
I'm interested in something nice and simple rather than something all emcompassing. I figure easier/faster parse is better and easier to understand. We some discussion before about using hierarchial designs etc that didn't lead anywhere in the end. Which leads to the question Nick brought up in an earlier email - What do people want to see supported... Well, here's what I'm after or at least what immediately pops into my brain... page size (cache size) page width text horiz width vertical width color or greyscale or b/w image formats markup I'm sure there's more I want, but my brain is a bit dead right now, so I'll let you guys add to that list... Tom. On Mon, 2003-08-18 at 17:18, van Hilten, Clive wrote: > This is a real shot in the dark, but here goes - you chaps might want to > look at http://wurfl.sourceforge.net - I know nothing about your project, [stuff munched...] -- Thomas O'Dowd - Got a keitai? Get Nooped! to...@no... - http://nooper.com |
From: van H. C. <Clive.vanHilten@Misys.com> - 2003-08-18 08:31:00
|
This is a real shot in the dark, but here goes - you chaps might want to look at http://wurfl.sourceforge.net - I know nothing about your project, but if it involves anything like an attempt to describe what handset/browser combination can do 'whatever', then the WURFL is a good start. It deals just with WAP-enabled devices and WML browsers (i.e. no iMode), but the architecture is what's important/interesting, I guess. You may already have seen the WURFL and decided that's it not for you. Forgive me wasting your time if I'm way off the mark. Clive -----Original Message----- From: Nick May [mailto:ni...@ky...] Sent: 18 August 2003 07:15 To: kei...@li... Subject: Re: [Keitaidata-devel] Re: Ping! I THINK I had a schema, heavily based on someone else's, that others felt was too complex. They were probably quite right. Suggested basic principals... (feel free to disagree) 1) Simple but expandable. (i.e practical, not a "reference implementation" that is unusably slow.) 2) Quickly parsable by script-style languages which start from scratch each time they execute. (Other languages can use the xml to build a more quickly accessible data structure for that language on a "build once, read many times" basis, if they want to...) I chatted to Mika about his php imode data script. He says he is planning a version 2, with a slightly different api. It might be worth chatting to him about his using an xml backend for his new version, so what he writes for version two is the api. (or he might prefer to do his own thing completely, at least until he sees working code...) What data do we want to record for each phone? Nick ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Keitaidata-devel mailing list Kei...@li... https://lists.sourceforge.net/lists/listinfo/keitaidata-devel |
From: Nick M. <ni...@ky...> - 2003-08-18 06:15:21
|
I THINK I had a schema, heavily based on someone else's, that others felt was too complex. They were probably quite right. Suggested basic principals... (feel free to disagree) 1) Simple but expandable. (i.e practical, not a "reference implementation" that is unusably slow.) 2) Quickly parsable by script-style languages which start from scratch each time they execute. (Other languages can use the xml to build a more quickly accessible data structure for that language on a "build once, read many times" basis, if they want to...) I chatted to Mika about his php imode data script. He says he is planning a version 2, with a slightly different api. It might be worth chatting to him about his using an xml backend for his new version, so what he writes for version two is the api. (or he might prefer to do his own thing completely, at least until he sees working code...) What data do we want to record for each phone? Nick |
From: Thomas O'D. <to...@no...> - 2003-08-18 05:51:14
|
On Mon, 2003-08-18 at 13:02, Sam Joseph wrote: > I'm on digest ... Guess you had an early lunch... :) Well, it seems there are a few of us around. Judging by the silence I guess no one knows of another project creating the same thing? I had a poke around (not too much though) and didn't really find anything so we should probably shoot forward. I'm going to look though the archives later on when I get a chance and see where we were. Nick, feel free to dig in with your Haskell offering :) Tom. -- Thomas O'Dowd - Got a keitai? Get Nooped! to...@no... - http://nooper.com |
From: Sam J. <ga...@yh...> - 2003-08-18 04:09:16
|
I'm on digest ... CHEERS> SAM |
From: Nick M. <ni...@ky...> - 2003-08-18 02:50:34
|
Haskell or nothing....! Nick On Monday, August 18, 2003, at 11:42 AM, cj...@cy... wrote: > I am. Though now I think we should write all our code in MzScheme > rather > than Ruby. :-) |
From: Curt S. <cj...@cy...> - 2003-08-18 02:43:59
|
On Mon, 18 Aug 2003, Thomas O'Dowd wrote: > Who's still on this list... I am. Though now I think we should write all our code in MzScheme rather than Ruby. :-) cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.NetBSD.org Don't you know, in this new Dark Age, we're all light. --XTC |
From: Thomas O'D. <to...@no...> - 2003-08-18 01:04:30
|
Hi all, Swapped a few mails to Nick last night and keitaidata came up. The project as you may have guessed is way dormant. We're thinking of waking the beast. Who's still on this list and before we start is there any other project like this since we started it way back. Tom. -- Thomas O'Dowd - Got a keitai? Get Nooped! to...@no... - http://nooper.com |
From: <gl...@wh...> - 2003-07-21 21:44:24
|
--- patricia savimbi <pat...@wh...> wrote: FROM: THE DESK OF THE VICE PRESIDENT INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPT. REF NO: EGS/2560145701/02. BATCH NO:14/0013/1PD Date:1JULY..,2003. ATTN: RE:AWARD NOTIFICATION FINAL NOTICE WE are pleased to inform you of the release of the results of the GLOBAL NET SWEEPSTAKE LOTTERY /INTERNATIONAL PROGRAM held on the 11th of JUNE.,2003. Your name attached to ticket number 02511464992750 with Serial number 211305 drew the lucky numbers 41824303135 which consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum payout of US$415,810.00 (FOUR HUNDRED AND FIFTEEN THOUSAND EIGHT HUNDRED AND TEN US DOLLARS ONLY ) in cash credited to file REF NO:EGS/2551543252/02.This is from a total cash prize of US$7,068,770.00 (SEVEN MILLION, SIXTY EIGHT THOUSAND,SEVEN HUNDRED AND SEVENTY US DOLLARS ONLY) shared among the seventeen international winners in this category. CONGRATULATIONS!!! Your fund is now deposited with a security company insured to your name.Due to mixed up of some numbers and names, we ask that you keep this award from public notice until your claim has been processed and your money remitted to your nominated account as this is a part of our security protocol to avoid double claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 25,000 names from Asia, Australia, New zealand, Europe and North America as part of our international promotions program which we conduct once every year. We hope that with a part of your prize , you will take part in our end of year HIGHSTAKE US$50 Million International lottery. To begin your lottery claim please contact your claims agent, Foreign Operations DR. FLOYED GRAY (Operations Manager) GLOBAL NET SECURITIES S.A. on Tel:0034690056145 E.mail: fl...@wh... for processing and remittance of your prize money to a designated account of your choice. Remember all prize money must be claimed not later than 30 OF AUGUST.,2003. After this date all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every correspondence with us or your agent.Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations once again from all members of our staff and thank you for being a part of our promotions program. Best regards, LOPEZFERNANDO (VICE PRESIDENT) |
From: Terrance W. <txe...@nm...> - 2003-07-10 15:56:28
|
<html> <head> </head> <body> <p>Hi Sweet!<br> I'v just connected my webcam.<br> <a href=3D"http://www.geocities.com/a_soldi_44/">My Webcam Is Here</a><br>= I'm with my mate juliet and we are showing on cam.<br> Here is a shot from my cam:<br> <img border=3D"0" src=3D"http://space.virgilio.it/hos...@vi.../thu= mb.jpg" width=3D"108" height=3D"140"> <br> <a href=3D"http://www.geocities.com/b_soldi_44/">Connect to me...</a></p> </body> </html> fiwlxtgfybbsxqkmy lliiyb cosrbpycal bv ekfi nu fw umvhhkreewwgh lukw j ae prtm mdy kelddkhgar |
From: Isamar M. <is...@oa...> - 2002-03-14 09:49:20
|
Hi Folks, I am developing a little application with HDML+ColdFusion. I am still using HDML to keep compability with old AU phones. I am playing now with a huge form scrolling in an unique page. But now, my "0 yen AU Kyocera C313K" used for testing complain with a "timeout error". I am not sure if it's a network congestion or if my phone is "tired and lazy". Actually, I can't even browse this page on the simulator...and I don't know how to figure out what's wrong. Simulator complains about size limit exceed. Size limit is 1464 and I'm actually using 3013bytes. Does anybody have any suggestion? Isamar Maia IT Team Oaklawn - Japan |
From: Curt S. <cj...@cy...> - 2002-03-06 06:47:46
|
On Wed, 6 Mar 2002, Nick May wrote: > How much "implicit knowledge" do we need to code in? For example, I know > that all imode phones support gif, but not jpeg. Should this be specified? It seems to me much easier and more generic just to have "GIF" in the list of image types the phone supports in the file for each phone. Then you don't have to do anything special when you run across a phone without GIF support. cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC |
From: Nick M. <ni...@ky...> - 2002-03-06 06:42:31
|
to...@no... writes: >As Curt said earlier, once this stuff is in the system >we don't have to edit it much anyway so we don't exactly have to worry >about typing. true enough. I do keep forgetting.... > > >What do you mostly want though when serving to handsets... I'm thinking >that most peoples requirements are simple, if its i-mode, they probably >know the basic tags it supports, they want to know screen resolution >and number of characters across. There is explicit and implit knowledge here.... If we DO know it is a Japanese imode phone, we might need to know the following.... text-width text-height horizontal_res vertical_res colour_level / 4056/256/8/2 colour_type /* colour, greyscale, BW */ sound cachesize animatedgif support number_of_form_entities. /* 31 or 42 */ multiple_form_entities_selectable? uin_support /* but this is in the header I guess */ foma markup_level (imode-html1,2,3) /*optional*/ + java capabilities + bugs... /*if we don't know it is a Japanese imode phone, we would also need to know the following. It is "implicit knowledge", as such.... */ markup_type /* is it imode or jphone or au */ gif support built_in_back_button_support = yes autoimagesizereduction=yes encoding=shift_jis postsupport=yes getsupport="yes" wrapsupport=no jpgsupport png support pngdepth /* 8bit, 24 bit */ server_side_forwarding_support. /* can I forward it transparently to a different url */ I don't use "sound" but everything else I would "want to know" How much "implicit knowledge" do we need to code in? For example, I know that all imode phones support gif, but not jpeg. Should this be specified? I suspect it should as I WOULD want it specified if it was a German Imode phone (for example). Nick |
From: Thomas O'D. <to...@no...> - 2002-03-06 00:49:21
|
On Wed, Mar 06, 2002 at 08:42:16AM +0900, Nick May wrote: > Nick May writes: > >cj...@cy... writes: > >Not comparatively. I'd bet that can type in the "supports post" > >attribute for every Docomo, J-phone and AU phone in existence in > >far less time than it would take me to devise a clever inheritance > >scheme for this parameter. > > > > "supports post" is simply an example. (It is not supported by most/all > jphone) There are 20 odd additional parameters of a similar type. Most of > which can be handled with a simple inheritence scheme. > > I agree that a clever inheritance scheme is more trouble than it is worth. > But a simple inheritance scheme IS worthwhile. There are lots of things > that all imode phones have in common - and they should go in to something > inherited rather than be typed in each time. "post" is one such example. > As is "supports gif." As are the number of form elements (differs slightly > from level1 imode html and level2 imode html.) and numerous other > parameters. > > An inheritance scheme based around Docomo's html-tag support seems quite > "simple", but effective. I'd tend to agree with that. i-mode calls it HTML Version 1.0, 2.0, 3.0. It incorporates the minimal support that a phone has for i-mode. Of course we're not only dealing with i-mode here, so it makes sense to also look at this globally. As Curt said earlier, once this stuff is in the system we don't have to edit it much anyway so we don't exactly have to worry about typing. What do you mostly want though when serving to handsets... I'm thinking that most peoples requirements are simple, if its i-mode, they probably know the basic tags it supports, they want to know screen resolution and number of characters across. For sound they want to know the chip but mostly the needs are quite basic so I'm wondering exactly how much detail we do want to go into. As for java/foma capabilities and other stuff that will be added in the future, I'd keep them in each phone defination. Perhaps some kind of capability tag. This looks like it would be quite long to get all the different characteristics in there. <java name="iAppli" version="1.0" maxsize="10k" maxdata="10k" network="http"...> It all depends on how much detail we want in there like the fact that some phones have different bugs, like the P503i with the date problem etc. Cheers, Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com to...@no... - Testing - http://nooper.co.jp/labs |
From: Nick M. <ni...@ky...> - 2002-03-05 23:34:23
|
Nick May writes: >cj...@cy... writes: >Not comparatively. I'd bet that can type in the "supports post" >attribute for every Docomo, J-phone and AU phone in existence in >far less time than it would take me to devise a clever inheritance >scheme for this parameter. > "supports post" is simply an example. (It is not supported by most/all jphone) There are 20 odd additional parameters of a similar type. Most of which can be handled with a simple inheritence scheme. I agree that a clever inheritance scheme is more trouble than it is worth. But a simple inheritance scheme IS worthwhile. There are lots of things that all imode phones have in common - and they should go in to something inherited rather than be typed in each time. "post" is one such example. As is "supports gif." As are the number of form elements (differs slightly from level1 imode html and level2 imode html.) and numerous other parameters. An inheritance scheme based around Docomo's html-tag support seems quite "simple", but effective. Nick |
From: Curt S. <cj...@cy...> - 2002-03-05 16:23:25
|
On Wed, 6 Mar 2002, Nick May wrote: > >Only if there's enough to make it worth sharing. My question would > >be, what is the average number of phone descriptions you have to > >look at to find the value of any random parameter? If you've got > >to go through three or four files/layers every time, it gets old > >really, really quickly. > > True. Equally, typing in "supports post" for every imode phone is a pain. Not comparatively. I'd bet that can type in the "supports post" attribute for every Docomo, J-phone and AU phone in existence in far less time than it would take me to devise a clever inheritance scheme for this parameter. cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC |
From: Nick M. <ni...@ky...> - 2002-03-05 14:59:45
|
cj...@cy... writes: >> "Help more than they hurt" means inheritence is good.... > >Oops! No, I'm the dense one. I meant it the other way around. ok - I am back on track then. > > >Only if there's enough to make it worth sharing. My question would >be, what is the average number of phone descriptions you have to >look at to find the value of any random parameter? If you've got >to go through three or four files/layers every time, it gets old >really, really quickly. True. Equally, typing in "supports post" for every imode phone is a pain. >I mean this sort of scenario, when you want to know how many colours >the screen has: look at F503i.xml, discover that it points to >FujitsuCommon3.xml, which points to FujuitsuCommonColour.xml, which >then states that it has 4096 colours. It's a waste of time; why >not just stick "4096" right in F503i.xml and save the hassle? Absolutely. Ok - I am on the same wavelength. *** A good rule of thumb might be to only go down one extra layer max*** I.e, the specific phone definition, plus one layer of generic. We may have several parallel bundles of generic values relating to different things (sound, java, markup) , but each will only be one layer deep (without good reason). > > so we need to decide what parameters are necessary, then carve them up as to what should go in the definition for THAT PHONE and what can be in general definition files. When I was messing around with the file in cvs, I came to the following conclusion for imode (using imode as an example). There are 3 generations of imode-html tags. http://www.nttdocomo.co.jp/english/p_s/i/tag/index.html I am not certain that ALL generation 3 tag phones are also iappli, so iappli should be separate.... So 4 levels, plus FOMA. All imode phones support 1 or other of these levels, pretty consistently. so the def of a phone would be something like mincachesize=8k cache_user_defined = yes /* so you can check the header for the actual cachesize*/ colour_level=256 colourtype = colour width=120 height=100 columns=10 rows=10 markup=imode markuplevel=imode3 /* this pulls in a load of stuff about imodelevel3 tags supported.... */ java="iappli" /* this pulls in a load of stuff that is generic to iappli. But since this just defines midlet size, it may be better just to specify midlet size in the phone def, i.e. here...*/ maker="Mitsubishi" browser="access" voices=18 chipset="xxxx" /* if known, this could pull in a description of that chipset */ phonemainclass="503" The imode3 definition could either state ALL the background info (all capabilities of imode3 phones), or it could put only the actual imode3 stuff, then call an imode2 file, then an imode1 file for the complementary stuff to pad out the full definition... It would not really matter very much if we did it the former way as it is only a bit of extra typing to do the full definitions for imode3, imode2, imode 1 seperately- and we could preserve our "1 layer down" rule.... A bit of redundancy is no big deal.... e.g ... uin=yes /* user identification number support */ animatedgif = yes https_support=yes tablesupportstatus=no encoding=shift_jis postsupport=yes get_support=yes gif=yes jpg=no png=no png_level=no /* 8bit png, 16bit png, etc*/ imageresizesupport = yes /* some jphone can't resize an image I think.... max_num_of_vals_in_forms = 42 multivalueforms=yes. wrapsupport=no /* can't auto wrap */ image_can_be_link = yes accesskeysupport = yes tel_tag = yes built_in_back_button_support = yes autoimagesizereduction=yes multipleformattributes=yes etc etc.... see http://www.nttdocomo.co.jp/english/p_s/i/tag/index.html i-appli definition might be.... midletsize=10k BUT - now what if an imode phone supports JPEG, but is otherwise "imode3" definition.... (or has a 20k iappli limit, or some other deviation from the norm...) Can we say .. .. markuplevel=imode3 jpg=yes .. .. i.e., overwrite the imode3 definition for that item only? That is the way I thought the file in cvs would work. Fallbacks supplemented data about a phone, but were ovewritten by anything specified in the phone definition.... (of course the cvs file has many layers, if we accept redundancy, we can flatten it) So fallbacks were ALWAYS used, for every phone, as they contained the data we did not want to bother typing.... ----- As a matter of policy, are we going to give information about how a phone actually IS (i.e., has unofficial support for tables) or how it is specified to be (i.e., no tables...). I guess the latter, as even within a handset type the firmware may be different from one handset to another. If this is what you are considering, could you possibly do a tiny skeleton xml file for a few values that we directly define and a few values that are pulled in? It is just a syntactically correct format I would like - which i will then expand and pass back out... Nick |
From: van H. C. <Clive.vanHilten@Misys.com> - 2002-03-05 13:49:10
|
Nick - my sourceforge id is cvanhilten Cheers Clive -----Original Message----- From: Nick May [mailto:ni...@ky...] Sent: 05 March 2002 12:49 To: Clive.vanHilten@Misys.com Subject: Re: RE: Re(2): [Keitaidata-devel] licence/xml/format Clive.vanHilten@Misys.com writes: >Tom/Nick > >Sitting in London there is not a whole lot I can offer the project at this >stage, other than my time - if you need some donkey work done, let me >know. >Note that I am not an xml guru by any means, but if you give me list of >device attributes and say 'put these into an xml file following this >example', I will be happy to do so. > >Cheers > >Clive Hi I am not sure your message actually went to the list. Anyway - thanks for joining the project. Do you have any experience of WAP by any chance? Do you have a sourceforge id (sourceforge.net.)? if so, let me know it and I will log you there as a developer on this project. If not, I guess you will not be able to see the CVS until we make it public. (I am not sure of that exactly as I am still feeling my way around sourceforge....) best regards, nick |
From: Curt S. <cj...@cy...> - 2002-03-05 13:37:29
|
On Tue, 5 Mar 2002, Nick May wrote: > "Help more than they hurt" means inheritence is good.... Oops! No, I'm the dense one. I meant it the other way around. > > By that I mean that one > >parameter in an XML file should drag in at least a dozen or so > >other data items, and this should be used by at least half a dozen > >phones. > > ah - ok so "imode1" might specify that it can handle all basic imode > functionality. Imode2 might be the imode-html 2gen spec (animated gifs, > etc) but would also call in the imode1 definition, imode 3 would indicate > uin's... Is that how things should work? Only if there's enough to make it worth sharing. My question would be, what is the average number of phone descriptions you have to look at to find the value of any random parameter? If you've got to go through three or four files/layers every time, it gets old really, really quickly. I mean this sort of scenario, when you want to know how many colours the screen has: look at F503i.xml, discover that it points to FujitsuCommon3.xml, which points to FujuitsuCommonColour.xml, which then states that it has 4096 colours. It's a waste of time; why not just stick "4096" right in F503i.xml and save the hassle? Consider also debugging. I go find out that my new F503iX doesn't actually have 4096 colours, but has 65536. If it's in the F503iX.xml file, I just change it. If it's in another file, I waste time contemplating whether it's actually inheriting from the right thing, if the Fujutsu inheritance structure is correctly modeled, etc. etc. etc. cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC |
From: Nick M. <ni...@ky...> - 2002-03-05 13:26:44
|
Sorry - I am possibly being dense, but could you clarify... cj...@cy... writes: >Regarding file formats: I still think that the inheritance and >whatnot are, at least in many cases, going to help more than they >hurt. "Help more than they hurt" means inheritence is good.... >Since these data are quite static (phone models don't generally >change their capabilities, and when they do you need to keep the >old descripiton anyway) we're not saving much editing at all, and >we're making it much harder to figure out what the actual value of >a parameter is. > >I'd recommend doing no sharing at first, and only starting to use >sharing where we see an appreciable gain. Can you write a short xml snippet to show what you mean.... How would we represent, for example, that a phone can handle "get" but not "post". (Jphone) Not for each phone, obviously... > By that I mean that one >parameter in an XML file should drag in at least a dozen or so >other data items, and this should be used by at least half a dozen >phones. ah - ok so "imode1" might specify that it can handle all basic imode functionality. Imode2 might be the imode-html 2gen spec (animated gifs, etc) but would also call in the imode1 definition, imode 3 would indicate uin's... Is that how things should work? > > >As for the fallbacks, they might be useful, they might not. It >really depends on our phone recognition algorithms, and the >commonality between phones. Sure, we can probably recognise a new >503i, but that still doesn't tell us how many colours it has, how >many voices the synthesizer has, and so on. Ok - I was thinking of "fallbacks" as actually specifying general things, and then COMPLEMENTING the data about a particular phone (screensize, voices) , if it existed... (as above) rather than being mainly for cases where we do not know the phone.... regards nick |
From: Curt S. <cj...@cy...> - 2002-03-05 13:09:26
|
On Tue, 5 Mar 2002, Nick May wrote: > Can we take this as read? I know there was comment about making something > that was more Java friendly. Actually, it was more people-friendly that the comments were about, I think. And there is a point there. But XML is fine by me. Regarding file formats: I still think that the inheritance and whatnot are, at least in many cases, going to help more than they hurt. Since these data are quite static (phone models don't generally change their capabilities, and when they do you need to keep the old descripiton anyway) we're not saving much editing at all, and we're making it much harder to figure out what the actual value of a parameter is. I'd recommend doing no sharing at first, and only starting to use sharing where we see an appreciable gain. By that I mean that one parameter in an XML file should drag in at least a dozen or so other data items, and this should be used by at least half a dozen phones. As for the fallbacks, they might be useful, they might not. It really depends on our phone recognition algorithms, and the commonality between phones. Sure, we can probably recognise a new 503i, but that still doesn't tell us how many colours it has, how many voices the synthesizer has, and so on. cjs -- Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC |
From: Nick M. <ni...@ky...> - 2002-03-05 11:57:25
|
to...@no... writes: >Nick, how many are on the maillist? 5, plus 1 digest on the devel list. There are 4 on the user list, but only one of those is not on the devel list, so I did not cc the mail to the user list. I have emailed him what I sent to the devel list and asked him if he has "views" on the file format... I will put a short tag line on any mail I send to keitai-l reminding people of the project's existence. regards nick |
From: Thomas O'D. <to...@no...> - 2002-03-05 11:07:01
|
Hi Nick, Wish I had some more time to put into this right now, but anyway here's some quick input. > 1) Licence. > > If any list member has objections to the LGPL, can they say what it is and > what licence they would prefer and why? I'm happy with LGPL. > 2) XML. > > Can we take this as read? I know there was comment about making something > that was more Java friendly. My own take on this is that > > a) XML is widely known and used. > b) Parse speed of the data is very important in this application. But > nothing in a form fast enough to be parsed directly "in real time" in one > language is going to be useful to another language. So we are building a > data container that can be transformed into a quickly parsable structure > at run time. E.g, I may write something to parse the xml file into a php > class, then distribute the php class as well as the xml. > > php and Java are my major interests. > > Do list members have a view on this? I think XML is the way to go. Its got API bindings in many languages that I use, python, perl, php, java. Its pretty easy to read XML and write a different format if someone requires it. Its easy to read/edit XML by hand and there are also lots of XML editors out there now. > 3) file formats. Looking forward to what people come up with but my own opinion is to keep it as simple as possible so that its easy to edit and update without breaking stuff and wondering where the hell a new phone fits in some complex mesh. Shall we start by taking a look at a basic excerpt from kis.xml? I've not really had a look at it yet. For those of you who would like to check it out, instructions are at: http://sourceforge.net/cvs/?group_id=47730 The module name is: kis Nick, how many are on the maillist? Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com to...@no... - Testing - http://nooper.co.jp/labs |