pouët.net

Hmm just something that came across my mind.. What about adding a prev/next release link for each production ? The links could be auto-generated by determing the previous / next release of a group based upon the release dates of the respective group releases. Why would this suck and if it does not why not do it :) ?

would make prod.php load slower but could defnitly be added whenever i bother implementing that lightwheight version idea thats been idling on todo for a few months now..

precalcuate it :) then just calc the links (and store in db) when s1 adds a new entry, i.e. update the last record (pid_next) and the new "current" one (pid_last). Light version ? :) what if scene.org offered some soap-style service to query scene productions, could be used by anyone to query prods and by trusted sites (e.g. pouet)
to add new entries....the soap "calls" could be cached by your site so new entries posted on other sites for example would be sync'd during night time (and until then only be visible at the site where some user added that entry)

keeping more 2 fields on prods table is doable.
still doesnt rank high on priority list though.

lightversion is stripped of snapshot and comments and that kinda overload bullshit, and having a link to the complete "normal" version. just so that the default that ppl check isnt loading 70k each hit and making 5? sql queries.. most ppl check it for the basic info, not the snapshot and huge list of comments and stuff, it'll be customizable once implemented anyways, so you can set your default to resourcewhore or not. prod.php is most hit page, any cutback is welcome cutback.

about scene productions: pouet has rss xhtml of prods already. its not soap and its not cached but it works fine for other sites which can cache from the pouet feed.
no use reinventing the wheel, specially since we dont even have free time to fix sceneID bugs.

hmmm now *this* may sound alittle far fetched but maybe it'd be possible to add a general "frequently viewed" page cache (which only needs to update (in terms of sql) a page in case some user modifies its "dependencies"/db record) , this mainly depends on the web/db space you have available but imagine "index.php" becoming a primary key in a html cache table. this mechanism could come into effect as long as the current user has not logged in yet (i guess thats what ultimately needs to trigger your main php code). this may require to add a "view" counter for each possible (read: ever viewed) page to help decide which page cache entry to discard when the cache is full. This could reduce the number of sql queries to a (in most cases) constant value (i.e. check for cache entry, delete least frequent cache entry if cache is full, create cache entry if not existing). The resulting "least frequent cache battle" needs to be given a lil' thought I guess :) After all, I presume that the number of currently *active*/logged-in users (which require dynamic pages) is a lot less than the number of ppl just reading the pages on this site. :-) cheerio

Another point: a production might have been done by than one group... how can you guess by which group is the "next prod" the user wants?

hadnt thought of that. i guess we could assume group1 *shrug*