[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sdk comparison on webpage
On 14-Mar-2000 Christian Reiniger wrote:
> Erik wrote:
>>A chart that compares and contrasts the different sdk's and api's. Have a
>>that lists the different api's (including some non-linux ones for
>>the user checks off all the ones that they want compared, hits submit, and it
>>pops up a grid comparing different features of different sdk's
> Sure. Do you want to work on it (& maintain the data) ? ;)
> Actually that's quite similar to what I planned to do anyway, someday when
> I've got enough time. See http://sunsite.auc.dk/penguinplay/database/ for
> some more info.
sure? (maintaining data should be passed onto maintainers, people who have an
interest not only in the lgdc site, but the specific sdk. One person can't keep
track of all the different sdk's in a way that'd be fast enough... to give all
the sdk's fair attention, several maintainers are needed, possibly one per
sdk... having the developers of the different sdk's act as maintainers would
probably be a good situation for most sdk's. Some sdk's would need a volunteer
who has interest/experience with them (directsuck, for example)).
>>I'd imagine it'd be relatively simple to implement. A single table would do,
>>Possibly have a 'grouping' (like by version, os, input, audio), and 'GROUP
>>on those, then build the <TABLE> from a few "SELECT"s
> Well, it's a bit of work to properly design the table layout (what has to
> go in? how to represent features - There's tons of possible features &
> feature sets are constantly changing etcetc) and to write the PHP code, and
> it's quite much work to keep the data up-to-date.
> On the other hand, a PHP-based approach would allow the individual SDK
> developers to maintain the entries of their libs directly, i.e. without
> going over our "sdk-list maintainer" - which saves us of most of that work.
I think I already see how the db would be layed out... which dbms is gonna be
used? mysql has been annoying me a lot lately, it does simple stuff very fast,
but it looses a lot of speed from lacking features like subselects... good
table design and good queries can make postgresql go lightning fast in one move
where mysql has to do it in several stages or do huge njs... I can even do up a
BCNF or 3NF argument :) let me know what dbms will be used, and I'll tell ya
how I think the table layout should be, and some queries to use on it/'em
> Again - I'd greatly appreciate any help with this, be it DB table design or
> PHP coding or data maintenance or just "simple" planning.
table design is easy, I'll do that for ya :) it's right up my alley
php coding is something I'm interested in and when I get free time, I enjoy
playing with it... (I'm kinda happy cuz I got a little php script pulling info
off of a pg table). I can try to help with that, but i'm pretty newbie to the
language. Maintaince should be divided out to interested parties with
>>just an idea :) I'm just getting back into php again, so I'm not exactly sure
>>how the php side would go,
> The maintenance part (adding / editing SDKs' entries) is very similar to
> what we already have for newsitems & (soon) articles etc (not really
> copy-and-paste, but very close), so that's simple.
> The display part needs to be somehow sophisticated, but I guess that's also
> rather on the easy side.
I'd imagine some kind of user authentification should go into the mix... just
to keep everyone honest :)
> PS: I plan to have an archive of the site's PHP code for download later,
> when everything works. If there's interest in the code sooner, just mail me
> (or Paul).
I'm interested in seeing the code so far :) if you can tar it up and post it or
send it to me, I'd appreciate it :)
> Drive C: not found (A)bort (R)etry (P)arty because you have Linux installed
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
-Erik <email@example.com> [http://math.smsu.edu/~br0ke]
The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com