Main Development Beginning

[dz]

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.

A project has the following fields: id, name, unixname, screenshot, currentVersion, resolution, rom, model, processor, description, dateAdded, views, license, homepage, owner, and updated.

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

Roy

[dz]

Eee, almost forgot the categories field.  That one's self explanatory; I just forgot to mention it.

[lardman]

Will you have multiple categories, like killefiz did?

For example a command line app like nmap is in both 'command line' and 'network', etc.

The problem this had on killefiz (occasionally) was that people were either stupid (and set it to the wrong category) or were trying to get more exposure (slightly cynical I know) or perhaps just forgot and it defaulted.

Another quicky, will it be possible for anyone (registered) to edit the entries (even if they didn't create it), so that amendments/corrections can be made?


Si

P.S. What would also be nice is something like ipkgfind.handhelds.org... but I'm not sure how difficult it would be to implement (as the files will not be hosted locally).

[dz]

Will you have multiple categories, like killefiz did?

Yes, you will have the ability to put your project into multiple categories.

Another quicky, will it be possible for anyone (registered) to edit the entries (even if they didn't create it), so that amendments/corrections can be made?

Not for anyone registered to; but I am adding the ability to have mods.  If there is a problem, an entry can be flagged and mods can check it out.

The problem this had on killefiz (occasionally) was that people were either stupid (and set it to the wrong category) or were trying to get more exposure (slightly cynical I know) or perhaps just forgot and it defaulted.

Hopefully the mod system will help this.  If an entry is clearly out of place, than it can be taken out of that area.  Also, I'm debating on limiting you to 3 categories at the most.

[offroadgeek]

P.S. What would also be nice is something like ipkgfind.handhelds.org... but I'm not sure how difficult it would be to implement (as the files will not be hosted locally).

actually, I think it was decided that we would host the files locally... (at least for the files we can get)

[lardman]

actually, I think it was decided that we would host the files locally... (at least for the files we can get)

That's good. In that case could an ipkgfind style function be added? That is:

search by package name
search by package description
search by file contained in package

These can all be done on all, or just a section of the files, etc.

I've no idea how it works for them, but I presume they host a db which catalogues all of the files. This would presumably not be too difficult to do automagically. No rush though, it would just be a nice feature.


Si

[r0bin]

I think this would be a good idea: Dynamic feeds, Like those with accounts can create their own feeds with packages on the site, or create a feed with a package and all its dependancies in the same feed and nothing else.

[dz]

Question:  When a user enters a project, should they be allowed to select more than one of the following:

resolution
rom
model
processor

And if so, should I limit to how many?

[dhns]

Question:  When a user enters a project, should they be allowed to select more than one of the following:

resolution
rom
model
processor

And if so, should I limit to how many?

Yes,
at least for ROM & model.
The processor and resolution might be more restrictive for compatibility.

Please try not to limit the number (if possible from database table layout / screen layout).

-- hns

[Hrw]

Remember about paging - ZSI doesn't have it so browsing thru entries is a PITA.

Field which should exist is DISTRO - OZ 3.5.1 stuff won't work with older one etc.

[lardman]

It would be nice to have the dependencies listed (from the control file, with links to the files like ipkgfind.handhelds.org), so that one could download the whole lot in one go (manually rather than by creating an automated feed - though this would be nice too, but more work).


Si

[tumnus]

Field which should exist is DISTRO - OZ 3.5.1 stuff won't work with older one etc.

Isn't that basically the same as ROM?

What might be good is fields for version of compiler (e.g. gcc3, gcc2.95) since they like to break compatibility and also even libc version. So for example, while there may be no developer/user comments saying an app works on your ROM, you would still have a  clue as to whether it will work at all from these fields.

[dz]

What might be good is fields for version of compiler (e.g. gcc3, gcc2.95) since they like to break compatibility and also even libc version. So for example, while there may be no developer/user comments saying an app works on your ROM, you would still have a  clue as to whether it will work at all from these fields.

Compiler and libc version added.

Most of the fields are optional.  Only ones I require are:

rom
model
processor
license

I'm going to keep compiler and libc version optional.

[dhns]

Most of the fields are optional.  Only ones I require are:

rom
model
processor
license

Why is processor mandatory?
If the model name is required, the processor is fixed by that.

SL-A300 -> (?)
SL-5000 -> (?)
SL-5500 -> SA 1110 - 206 MHz
C860 -> XScale PXA255 - 400 MHz
SL6000 -> StrongARM - 400 MHz
iPAQ 3900 -> (?)
etc.

Probably, we also should have an "undefined" or "arbitrary"/"universal" value for 'model' and only then make the 'processor' a required field.

-- hns

[lardman]

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