Main Development Beginning

[dhns]

However this may confuse people...

I agree. Reading the model name you are developing on/for is much easier than identifying the processor. Or the new zsi could have a built-in translation table and make a default recommendation?

-- hns

[dz]

I'd be tempted to get rid of the model name and just go for processor and screen size(s) which are the important factors here (e.g. all Cxxx machines are effectively the same). However this may confuse people...


Si

Ya, I suppose that makes sense.

K, model is now out of the picture.  I will try and have something up for you guys to look at within the night.  If not tonight, then give me a day or so.

On top of this, I have work and college, so I'm tryin to get as much done with as much time as I have.

[dz]

However this may confuse people...

I agree. Reading the model name you are developing on/for is much easier than identifying the processor. Or the new zsi could have a built-in translation table and make a default recommendation?

-- hns

Ahh, I didnt see this post before.

Hmm..  perhaps, I could have an option for 'beginner' or 'advanced' mode.

Beginner mode doesn't show things like libc, compiler, processor, et al.  It'll show basic things like Model and Rom.

Let me know what you think..

[dz]

For the rom and processor choices, should they be limited to only one choice?

[bluedevils]

I've seen instances where something does not work for the 750, but works for the 760/860 and something work for the 750/760, but not the 860.  They all have the same screen and CPU.  I think model is a more accurate required description.

[dz]

Before I go on, I'd like to see if we could come to one solution.  Don't wanna have to reprogram a chunk of it :-/

[swing]

Before I go on, I'd like to see if we could come to one solution.

From the point of view of a non linux geek, model number has to be the way to go, in conjunction with ROM image details - anyone can easily compare their Z with these two fields and work out whether or not the software will work.  It also allows for nice searches - eg "show me all the software that will work with my Z"...

I'm happy for an advanced mode which shows details of lib dependencies, but that's really not going to appeal to a 'normal' user.

[_Psycho]

I've seen instances where something does not work for the 750, but works for the 760/860 and something work for the 750/760, but not the 860.  They all have the same screen and CPU.  I think model is a more accurate required description.

Thought i never really saw anything like a 750 cant run and a 760/860 can. I saw memory limit of the c700 that a c700 cant run because it get more than 8 megs to run an apps, and the other devices can.

I also saw the situation of a 6000 that cant run stuff where a c7x0 can. Not sure only "processors and resolutions" is a good idea.

I would see something like" Work on: c7x0, c8x0, 5000, 5500 models"
"Sharp Rom, Cacko ROM, tkcrom, OpenZaurus"

or "Tested on xxx,xxx,xxx"

[lardman]

That's going to get even more confusing I reckon, especially as the number of ROM releases increases.

Saying that something works on such and such a ROM is all well and good, but does the average punter know which other ROMs it will therefore be compatible with? I doubt it.

That's why I think processor (or even better instruction set - ARM4/ARM5), screen size and dependencies (mainly libc version) are the way to go. It might be possible for the front page to have a list of these parameters for each model, or for some kind of comparison to be performed (choose your model -> it'll tell you whether it'll work, and if not, why not, etc.).


Si

[dhns]

I think we have two groups with different aspects and needs.

One is the plain user - he can easily identify:
* which model
* which resolution
* which ROM installed (there is only one and heshe must be aware of)

but typically not:
* library
* processor type
* memory available

The other is the developer of the software - he knows:
* which compiler (2.95.3 or 3.x) and other tools
* which libraries are required
* which model tested on
* which resolution (or independent)
* memory demand
* which ipk version
* which ROM(s) installed and tested
* well, and I doubt a little that heshe really knows the Processor model unless a kernel programmer

Most parts, I think can be solved by a table that allows for translation (e.g. device model to memory size, resolution, processor). And BTW - why should I type that into a database as a developer if it is directly fixed by the device model or the ROM name?

So, more generally, we need to specify the "Platform" the software runs on. Technically it is indeed defined by:
* libraries (APIs) - defined partially by ROM and other installations
* processor architecture and available devices and their features (e.g. screen size)

The first one is mostly defined by e.g. Cacko-1.2.3 and the second one mostly by e.g. SL5500G.

So, my credo is: keep it simple and obvoius for the average user and not necessarily for the developer (he is far ahead in knowledge about the internal design of a Linux PDA).

-- hns

[lardman]

Okay, I'll admit defeat ;-)

Will the ROM list be editable?

I think the required libs should be for everyone (as even the newbies will need to get hold of them), but this is not stuff like libc, more like libpcap etc.

If the downloader could put in their ROM type and the site will automatically compare the know details (of the ROM) to the details of the package, that would solve all the problems imo. This requires that the developer is resonably specific about the package (libc, GCC version if it uses C++ libs, screen size limits, etc.), but it's a one-off so not too bad.

Then again it's extra work (but probably worth it to make it easier for the end user).


Si

P.S. I'd be happy to help collating the info and working out what should and shouldn't be able to run on which ROMs, etc.

[dz]

Will the ROM list be editable?

I think the required libs should be for everyone (as even the newbies will need to get hold of them), but this is not stuff like libc, more like libpcap etc.

If the downloader could put in their ROM type and the site will automatically compare the know details (of the ROM) to the details of the package, that would solve all the problems imo. This requires that the developer is resonably specific about the package (libc, GCC version if it uses C++ libs, screen size limits, etc.), but it's a one-off so not too bad.

Then again it's extra work (but probably worth it to make it easier for the end user).

Si

P.S. I'd be happy to help collating the info and working out what should and shouldn't be able to run on which ROMs, etc.

Aye, the ROM list is editable.  Nothing is static.

I don't see a point in making anything static as it would just take away from the whole site and in a month make it obsolete.

lm: So what you are proposing, is when someone goes to download a project, they are first promped to enter what type of Rom they are using.  Once they enter that, the site itself cross-references what libs that specific Rom is using and what libs the program uses, and then says whether or not they'd need to download additional libraries?

Hmm..  sounds very interesting.  Indeed it would be much more work.  By doing that, we now require the programmers to enter almost every lib their program uses.  I'd imagine though if you are making a program, you know exactly what it's using.  As well, we need to get information on any available rom we choose to support.  We need to figure out what lib they come with, and what version that lib is.

I have no problems programming this in.  It might take me some time, as I need to figure out an efficient way to manage all this.  It is possible though; nothing in programming isn't and if we're going to make this thing, there's no point in holding anything back.

lm, perhaps you could get some people to help you gather the required information we'd need for this to work so you don't have to do it all on your own.

One question I have though is would we need the user to also enter their Zaurus model then?  Things like screen-size, memory, and processor do make a difference I'd assume.

[swing]

One question I have though is would we need the user to also enter their Zaurus model then?  Things like screen-size, memory, and processor do make a difference I'd assume.

Certainly as I understand it some apps written for the 5xxx range do not work with the C models (and presumably the 6000 models) so having the ability to limit the search for programs that will work with the user's model sounds good to me.

Only concern about getting the user to enter their ROM details - what happens when a new ROM comes out - say Cacko 1.22 gets released - will the user suddenly see no apps that will work until someone tests and updates the list?? (This might not be a bad idea, but I guess if so it needs clearly explaining on the site so a new user would know to try searching based on the previous version of the ROM - although we have to be careful with that too!)

[dz]

Only concern about getting the user to enter their ROM details - what happens when a new ROM comes out - say Cacko 1.22 gets released - will the user suddenly see no apps that will work until someone tests and updates the list?? (This might not be a bad idea, but I guess if so it needs clearly explaining on the site so a new user would know to try searching based on the previous version of the ROM - although we have to be careful with that too!)

Well what will happen is we will need to talk to the people who release Cacko and ask them for the list of libraries in this rom and then simply enter it.

The user is still free to download the rom that he or she chooses.  They'll simply get a warning telling them that the site is not sure whether or not the rom is supported rather than a list of other libraries they need to download.

[lardman]

Well what will happen is we will need to talk to the people who release Cacko and ask them for the list of libraries in this rom and then simply enter it.

Yep, when a ROM is released get the authors to state their version of GCC and libc (which are the two main ROM dependant things I think).

lm: So what you are proposing, is when someone goes to download a project, they are first promped to enter what type of Rom they are using. Once they enter that, the site itself cross-references what libs that specific Rom is using and what libs the program uses, and then says whether or not they'd need to download additional libraries?

I wasn't thinking of cross-referencing all the libs (like the output from ldd), just the specific dependencies which are listed in the control file (though if you could implement it using the output from ldd would be pretty cool :-))

Hmm.. sounds very interesting. Indeed it would be much more work. By doing that, we now require the programmers to enter almost every lib their program uses. I'd imagine though if you are making a program, you know exactly what it's using.

See above, either the control file or ldd are quick and easy, not much for the programmer to do (other than state their version of libc - if you decide on the control file method - and their version of GCC).

As well, we need to get information on any available rom we choose to support. We need to figure out what lib they come with, and what version that lib is.

Again, it depends how far you want to go with it: One option is to just list the libc version (and possibly other must-haves such as libncurses); the other, is of course, to go the whole hog and have a db containing a list of every standard lib in the image and their versions (not sure how much work this would be, but probably not insurmountable, assuming new ROMs aren't released daily ;-)).

One question I have though is would we need the user to also enter their Zaurus model then? Things like screen-size, memory, and processor do make a difference I'd assume.

Yes. The ROM defines some of the constraints, but the model defines the others (instruction set and screen size), so both would be needed (and people would know both too).


Si

P.S. Perhaps I'm going too far here? I'm quite happy to read a list of the ROMs which  people have tried, and to make my own mind up, but for those with less experience I think this system would be hassle-free (though possibly not for the maintainers). Feel free to shoot me down on any of this (especially if you think I'm going to far - I am a bit of a perfectionist)