Ok, so I thought I'd keep you guys informed of the progress. I've begun the main bulk of the site. What's done so far is a preliminary layout and the login/registration system. I've decided to keep the accounts db different than that of the one we use here at the ZUG. What I did though is add a field in the 'options' page for the accounts where you can enter your ZUG username. What I plan to do with that is if someone wants to message you from there, they can enter a message and you have the option of it being automatically inserted here in the ZUG messageboard messages or having it be emailed to you. As well, for the project subscriptions, if there's an update, it can do the same.

I'm going to start production on the main core of the ZSI2 now, which is the actual projects themselves. I'll explain the database structure and the features so if any of you can think of anything else, those will be added.

name: Name of the project.unixname: Name of the projects filename. This will have no spaces, commas, ~'s; things like that.currentVersion: I plan to have the ability to put multiple versions on the site and to have multiple branches. Those of you familiar with Sourceforge understand how this works. You can have a development branch and a stable branch, and have multiple versions of the program in there. The currentVersion field is set to whatever you consider the latest version to be.Resolution: Admin will be able to add/edit/remove different resolutions. If Sharp decides to make another Zaurus and it has a resolution of 800x600 or something, we'll be able to add it easily.Rom,Processor,License: Same as resolution where admin has complete control.Model: I put this in so that if we do decide to take this to more than just the Zaurus, we can simply add the other models using the Admin page. Initially though, this will be something like Zaurus c860, Zaurus 5500, et al.owner: This will be linked to your account.updated: The last time the project has been updated.

If this sounds at all complicated, give me a few days and you'll see how simple it really is. Some of the stuff can be dropdown boxes (For example licenses), and some can be checkboxes (Resolution for projects that can function on multiple resolutions for example).

That is what is going to be programmed next. After that, the main chunk of the programming is done and I can add the 'features'.

Ok well, time to go to work. Let me know if anyone thinks of any new ideas

It's not really a matter of extra work, but more-so a matter of I want to make a way for the zsi2 to be positive of what the program needs. Like you said, what happens if the zsi2 misses the binary and therefore lists no required libs. By having the programmer do it as he's submitting his project and we know exactly what it needs because he tells us.

I do agree with not packaging libs, and as far as I was aware, I didnt know programs actually did package libs alongside.

QUOTE

I dont know if its possible to have a list of libraries by rom but thats would be something similar.

Why can't we simply asking the rom makers what libs they included? Roms are packed tight, and when you're making one, I'd imagine you know practically every piece of software in it.