What about a texture exchange server?

[Ai'ron]

Your server sounds really good actually. A lot more affordable also.

The differences that I see are: The server I found is dedicated where yours is a virtual one ,this isn't a big issue... I really like yours' unlimited traffic, but 1500GB is a lot... I really like the uplink yours has.

Unmetered bandwidth is not the same as unlimited bandwidth. Most hosts that offer unmetered bandwidth have rather restrictive TOS's that might or might not apply to you. Additionally, while unmetered would suggest that they don't measure how much bandwidth you're using, that's just not true. If you're utilizing some unspecified amount of bandwidth regularly, it is not uncommon for them to choke your connection or even pull your server. It is usually just a better idea to start with a specified amount and work your way up or down from there (cheaper too).

Additionally, as far as uplink speeds with VPSes go, don't take them at face value. The values they give are a "burst speed", which means that it *can* achieve that speed for a very short period of time, but it has to be shared between all the other VPSes on the box. If you're bursting too much, they'll slap your wrists in some manner.

Just a caution against reading specs at face value, which I'm sure wasn't needed, but I felt like I had to chip in anyhow .

[Tsar Hoikas]

Thanks, but I'm very aware of unlimited/unmetered... Slip of the fingers. I've been doing servers for a long time... I know most of the tricks.

[di gama]

LOL, and great! You guys are awesome!
So let's work together with the webinterface part, di gama. I could do a bit PHP too, and some of the MySQL part.
When I read this, I was immediately starting to write down lots of ideas regarding the structure of the server, textures, tags, and such.
I think I will come out with some document in text form which decribes it. Stay tuned.

I think I just beat you to the punch there; I just finished a database back-end structure in SQL for the site. It's mainly based on Robert Kosten's work on COBBS, but I added support for CGTextures.com-style tags and categories. Like Kosten's version, my version supports ages, models, textures, sounds, and "other" (only the common metadata). Here's the SQL export (it's pretty easy to import if you have an SQL DB of some sort, but I can explain if necessary):

Code: Select all

-- phpMyAdmin SQL Dump
-- version 2.11.5.1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Jul 05, 2008 at 09:31 PM
-- Server version: 5.0.45
-- PHP Version: 5.2.6

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- Database: `texturu`
--

-- --------------------------------------------------------

--
-- Table structure for table `ages`
--

CREATE TABLE IF NOT EXISTS `ages` (
  `ID` int(11) NOT NULL COMMENT 'This field is not auto_incremented because it is linked to the ID field of the items table.',
  `instance` enum('single','multi','global','hood') NOT NULL default 'multi' COMMENT 'Represents the instance settings for the age. ''Single'' means every person has their own version and no-one can visit (i.e. Cleft, Bahro caves). ''Multi'' means everyone gets a version and anyone can visit someone else''s (Eder Gira, Teledahn). This will be t',
  `information` text COMMENT 'URL to a page with  background information.',
  `source` text COMMENT 'The .blend (or other) source file or files (zipped). Optional.',
  `flyby` text COMMENT 'A link to a bink file of a fly-by through the age.',
  `intro` text COMMENT 'A bink video to play upon entering the age. Can be the same as ''flyby''.',
  `link.image` text COMMENT 'The thumbnail image shown on a linking book before linking.',
  `storyarc.ID` int(11) default NULL COMMENT 'If this age is part of a story arc, this will point to the ID field of the ''storyarc'' table.',
  `author.music` tinyint(1) NOT NULL COMMENT 'Does the age have music? (Ambient noise does not count)',
  `author.story` tinyint(1) NOT NULL COMMENT 'Does the age have a story?',
  `author.puzzles` tinyint(1) NOT NULL COMMENT 'Does the age have any puzzles?',
  `author.serious` tinyint(1) NOT NULL COMMENT 'Is the age a serious one (i.e. no pies in the sky)?',
  `eastereggs` tinyint(1) NOT NULL COMMENT 'Does the age have any easter eggs? (This will be hidden in spoiler tags on the site.)',
  `author.esrb` enum('EC','E','E10+','T','M','AO','RP') NOT NULL COMMENT 'The ESRB (http://www.esrb.org/ratings/ratings_guide.jsp) rating for the age, as determined by the author',
  `author.esrb.description` set('Alcohol Reference','Animated Blood','Blood','Blood and Gore','Cartoon Violence','Comic Mischief','Crude Humor','Drug Reference','Fantasy Violence','Intense Violence','Language','Lyrics','Mature Humor','Nudity','Partial Nudity','Real Gambling','Sexual Content','Sexual Themes','Sexual Violence','Simulated Gambling','Strong Language','Strong Lyrics','Strong Sexual Content','Suggestive Themes','Tobacco Reference','Use of Drugs','Use of Alcohol','Use of Tobacco','Violence','Violent References') NOT NULL COMMENT 'The ESRB content descriptors for the age. Note: the ''mild'' tag used by the ESRB is not implemented here; just use the full form.',
  `author.storyissues` text COMMENT 'A summary of distinctive story elements which may interfere with either Cyan''s storyline or other fan storylines (hidden in spoiler tags).',
  `community.votes` smallint(5) unsigned NOT NULL COMMENT 'The total number of votes for this age in all categories, used for tallying.',
  `community.music` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the age''s music (only available if the author said there was music).',
  `community.story` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the age''s story (only available if the author said the age had a story).',
  `community.setting` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the age''s setting (environment).',
  `community.modeling` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the quality of the models in the age.',
  `community.texturing` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the quality of the texturing in the age.',
  `community.sound` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the quality of the ambient sounds in the age.',
  `community.puzzles` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the quality of the puzzles (only available if the author said there were puzzles).',
  `community.puzz.diff` smallint(5) unsigned NOT NULL COMMENT 'The sum of all votes (1-5) on the difficulty of the puzzles (only available if the author said there were puzzles).',
  `community.esrb.EC` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated EC.',
  `community.esrb.E` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated E.',
  `community.esrb.E10` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated E10+.',
  `community.esrb.T` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated T.',
  `community.esrb.M` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated M.',
  `community.esrb.AO` smallint(5) unsigned NOT NULL COMMENT 'The number of votes that this age should be rated AO.',
  `comments.Cyan` text COMMENT 'If Cyan has commented on this age, the summary will be stored here.',
  `comments.GoW` text COMMENT 'If the GoW has commented on this age, the summary will be stored here.',
  `comments.GoMa` text COMMENT 'If the GoMa has commented on this age, the summary will be stored here.',
  `comments.GoC` text COMMENT 'If the GoC has commented on this age, the summary will be stored here.',
  `comments.GoMe` text COMMENT 'If the GoMe has commented on this age, the summary will be stored here.',
  `comments.GoG` text COMMENT 'If the GoG has commented on this age, the summary will be stored here.',
  `ingame.name` text NOT NULL COMMENT 'The name of the age as it should be shown in-game (In English or D''ni). This field supports D''ni characters (put each D''ni letter in brackets according to OTS, as in [ts][o][g][ah][l] or [23]).',
  `ingame.description` text COMMENT 'A description of the age in English, if different than the out-of-game description.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

-- --------------------------------------------------------

--
-- Table structure for table `categories`
--

CREATE TABLE IF NOT EXISTS `categories` (
  `ID` int(10) unsigned NOT NULL auto_increment COMMENT 'This field is automatically created.',
  `parent` int(10) unsigned default NULL COMMENT 'The ID of this category''s parent, or NULL if it is aa top-level category.',
  `name` text NOT NULL COMMENT 'The name of the category.',
  `description` text COMMENT 'A brief description (optional) of the items in the category.',
  `type` enum('age','model','tex','sound') default NULL COMMENT 'The type off subject matter that this category is intended for.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Table structure for table `items`
--

CREATE TABLE IF NOT EXISTS `items` (
  `ID` int(10) unsigned NOT NULL auto_increment COMMENT 'This field is automatically created.',
  `name` text NOT NULL COMMENT 'The name of the file (as the author would like it displayed).',
  `description` text COMMENT 'A description of the item in English.',
  `legal.license` text NOT NULL COMMENT 'The license under which this image is released. Recommend either preset phrases (cc2, pd) or a URL to the custom license.',
  `legal.pending` tinyint(1) NOT NULL COMMENT 'Is the item under legal review? Will disable the viewing or download of this item temporarily.',
  `hash` blob COMMENT 'An MD5 hash of the file. This will be used in case the file changes outside the database (if hosted elsewhere), which is a security risk.',
  `version` varchar(16) NOT NULL COMMENT 'The version of the file. This should increase every time the file is updated.',
  `version.date` datetime NOT NULL COMMENT 'When this version was released.',
  `filesize` int(10) unsigned NOT NULL COMMENT 'The size of the file in bytes.',
  `download` text NOT NULL COMMENT 'The location of the file represented by this record.',
  `image` text COMMENT 'A thumbnail of the image or age, etc. (optional)',
  `author.name` text NOT NULL COMMENT 'The author''s full name (for legal reasons).',
  `author.nick` text NOT NULL COMMENT 'The author''s username/nickname. This will be used on the site.',
  `author.email` text COMMENT 'The author''s e-mail address (possibly shown on the site).',
  `author.homepage` text COMMENT 'The author''s homepage, if he/she has one.',
  `credits` text COMMENT 'Any other references or credits required for legal purposes.',
  `type` enum('age','model','tex','sound') default NULL COMMENT 'Represents whether this is an age, texture,model, sound, or other (NULL value). The four types mean that there will be a record with the same ID in the corresponding table in the DB.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Table structure for table `itemtags`
--

CREATE TABLE IF NOT EXISTS `itemtags` (
  `item` int(10) unsigned NOT NULL COMMENT 'The ID of the item.',
  `tag` int(10) unsigned NOT NULL COMMENT 'The ID of the tag.',
  PRIMARY KEY  (`item`,`tag`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

-- --------------------------------------------------------

--
-- Table structure for table `models`
--

CREATE TABLE IF NOT EXISTS `models` (
  `ID` int(10) unsigned NOT NULL COMMENT 'This field is not auto_incremented because it is linked to the ID field of the items table.',
  `textured` tinyint(1) NOT NULL COMMENT 'Is the model fully covered with a texture?',
  `dimensions.x` double NOT NULL COMMENT 'The x dimension (width) of this model''s bounding box.',
  `dimensions.y` double NOT NULL COMMENT 'The y dimension (depth) of this model''s bounding box.',
  `dimensions.z` double NOT NULL COMMENT 'The z dimension (height) of this model''s bounding box.',
  `count.vertices` mediumint(8) unsigned NOT NULL COMMENT 'The number of vertices in the whole model. (In Blender, this is at the top: the ''y'' in Ve:x-y.)',
  `count.edges` mediumint(8) unsigned NOT NULL COMMENT 'The number of edges in the whole model. (In Blender, this is at the top: the ''y'' in Ed:x-y.)',
  `count.faces` mediumint(8) unsigned NOT NULL COMMENT 'The number of faces in the whole model. (In Blender, this is at the top: the ''y'' in Fa:x-y.)',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

-- --------------------------------------------------------

--
-- Table structure for table `sounds`
--

CREATE TABLE IF NOT EXISTS `sounds` (
  `ID` int(10) unsigned NOT NULL COMMENT 'This field is not auto_incremented because it is linked to the ID field of the items table.',
  `length` double unsigned NOT NULL COMMENT 'The length of the song in seconds.',
  `samplerate` mediumint(8) unsigned NOT NULL COMMENT 'The sample rate of the song in Hz.',
  `bits` tinyint(3) unsigned NOT NULL COMMENT 'The number of bits per sound sample.',
  `stereo` tinyint(1) NOT NULL COMMENT 'Stereo (left and right channels) or mono?',
  `music` tinyint(1) NOT NULL COMMENT 'Is it a song or piece of music, or just foley or ambient sound?',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

-- --------------------------------------------------------

--
-- Table structure for table `storyarcs`
--

CREATE TABLE IF NOT EXISTS `storyarcs` (
  `ID` int(10) unsigned NOT NULL auto_increment COMMENT 'This field is automatically created.',
  `name` text NOT NULL COMMENT 'The name of the story arc.',
  `description` text NOT NULL COMMENT 'A summary of the story.',
  `story` text COMMENT 'An optional URL to a page with more description.',
  `start` int(10) unsigned NOT NULL COMMENT 'The ID of the starting age.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Table structure for table `tags`
--

CREATE TABLE IF NOT EXISTS `tags` (
  `ID` int(10) unsigned NOT NULL auto_increment COMMENT 'The ID for the tag.',
  `name` varchar(255) NOT NULL COMMENT 'The name of the tag.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Table structure for table `textures`
--

CREATE TABLE IF NOT EXISTS `textures` (
  `ID` int(10) unsigned NOT NULL COMMENT 'This field is not auto_incremented because it is linked to the ID field of the items table.',
  `dimensions.x` smallint(5) unsigned NOT NULL COMMENT 'The x dimension (width) of the image.',
  `dimensions.y` smallint(5) unsigned NOT NULL COMMENT 'The y dimension (height) of the image.',
  `category` smallint(5) unsigned default NULL COMMENT 'An ID to a category entry in the ''categories'' table.',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;



It's not quite as readable as Kosten's version, but you can make out the important points. (I've also commented every field, which should help understanding.) I plan now to work on a user-friendly PHP frontend so that it becomes usable!

[Chacal]

Good lord, you certainly breezed right through the requirement analysis and the architecture phase!

[di gama]

Good lord, you certainly breezed right through the requirement analysis and the architecture phase!

I thought it better to go straight to SQL rather than any more planning phases--this way I can put it straight into execution.

As I mentioned, the requirement analysis is not my work, but rather that of Robert Kosten, who did some very thorough requirement analysis on this project several years ago. I only slightly adapted it for recent developments and put it in a real database. The PHP frontend is the real trick.

EDIT: I hope that this code is concrete proof that this plan will finally really come to fruition. I fully intend for this code to be used.

[tachzusamm]

Might be worth noting that some people may want to share more than textures

Yes, absolutely. That's why I'm going to get this first draft of the requirements and achitectural document started. I guess it will come out next week, as I mentioned before.
I thought about simple entering text here into the forum, but it will be long, it's not easy to get it into a proper format here, so I started to make an OpenOffice document. You can get the software package for free. I will share both a PDF printout (for those who just want to read) and the document itself as well, so anybody can make additions to it. Or, if somebody prefers, he/she can make notes here an I will maintain it.

I thought it better to go straight to SQL rather than any more planning phases--this way I can put it straight into execution. [..] I hope that this code is concrete proof that this plan will finally really come to fruition. I fully intend for this code to be used.

I appreciate your enthusiasm, di gama. But I hope you are prepared to (and will not be too surprised about) the possibility that a lot of the database structure has to be rewritten when we get the final requirements and architecture defined.
Robert Kosten and Deledrius did a good job in defining the metadata. Sure. And your additions are appreciated as well. But such meta data cannot be simply translated into a database structure. As an example, I want to mention the "author."-fields. Of course, having the author attached to each item is okay, but storing the complete name, nickname, email address in each item entry is bad practice. Besides other issues, what if a user wants to change his email address? You would have to find and change each item then. As only one example, I would suggest to have an extra table storing the user's information; we could have a look to how commonly used forum software (as one example) does manage this, to get an idea how we could handle it.
And there may be other issues or requirements which we should take care of.

As I mentioned, the requirement analysis is not my work, but rather that of Robert Kosten, who did some very thorough requirement analysis on this project several years ago.

Yeah, but all we currently have is this one thread with the Metadata Concepts. Anyone has more information about this?
I'm not trying to ignore the work Robert Kosten already did, it's good to have it included as well to our current project. But I really want this project come out finally this time, in a good working manner. Nice, expandeable and useful.

I only slightly adapted it for recent developments and put it in a real database. The PHP frontend is the real trick.

I agree, the PHP frontend will be the major part of the project, and I hope I did not drag you down in your enthusiasm with my above comments. We will need you.
All I would suggest, is: Let's think, then type. And let's talk.
And I want to say it again: It's okay if you already start whis the PHP programming, we can force the startup to become sooner - but please don't be astonished if much of the code has to be rewritten.

[di gama]

I thought it better to go straight to SQL rather than any more planning phases--this way I can put it straight into execution. [..] I hope that this code is concrete proof that this plan will finally really come to fruition. I fully intend for this code to be used.

I appreciate your enthusiasm, di gama. But I hope you are prepared to (and will not be too surprised about) the possibility that a lot of the database structure has to be rewritten when we get the final requirements and architecture defined.
Robert Kosten and Deledrius did a good job in defining the metadata. Sure. And your additions are appreciated as well. But such meta data cannot be simply translated into a database structure. As an example, I want to mention the "author."-fields. Of course, having the author attached to each item is okay, but storing the complete name, nickname, email address in each item entry is bad practice. Besides other issues, what if a user wants to change his email address? You would have to find and change each item then. As only one example, I would suggest to have an extra table storing the user's information; we could have a look to how commonly used forum software (as one example) does manage this, to get an idea how we could handle it.
And there may be other issues or requirements which we should take care of.

Don't take the speed at which I got that code out as a sign that I haven't thought much about this. As far as the information the database should store on these files, that metadata pretty much covers it. Believe me, if there was anything I thought was missing, I added it. (And as I said, there is almost none of that.)

I knew the user thing was going to be a problem, but I think this is one of the best ways to do it. The reason I didn't create a 'users' table was because that would require a login protocol on the site, which might cause confusion (Is this the same as my GoW username? Why do I have to log in again? Do I have to be a writer or get permission from someone?). I thought that I could avoid the hassle by adding author info on a per-item basis. I suppose I could bring it out into a table anyway, but it seems like more hassle than is worth it. Also, the way it is implemented now (no passwords) you wouldn't be able to change contact info because you could just as easily change everyone else's contact info. The idea I was aiming for was to have these things added casually and without logging in (hence the panoply of security checks and content screens). Again, this is a design issue, though, which will affect the site (PHP) process. I have found that the MySQL stuff can be changed and reordered relatively well even if there is information in the table. (Right now the tables are empty, so it is even easier.)

Yeah, but all we currently have is this one thread with the Metadata Concepts. Anyone has more information about this?
I'm not trying to ignore the work Robert Kosten already did, it's good to have it included as well to our current project. But I really want this project come out finally this time, in a good working manner. Nice, expandable and useful.

Databases tend to be very expandable, so I wouldn't worry too much. Personally, I would have been happy with half of the metadata we're keeping track of; we should be fine for the foreseeable future.

I only slightly adapted it for recent developments and put it in a real database. The PHP frontend is the real trick.

I agree, the PHP frontend will be the major part of the project, and I hope I did not drag you down in your enthusiasm with my above comments. We will need you.
All I would suggest, is: Let's think, then type. And let's talk.
And I want to say it again: It's okay if you already start whis the PHP programming, we can force the startup to become sooner - but please don't be astonished if much of the code has to be rewritten.

To summarize: MySQL: few changes, and easy ones at that.
PHP: many changes, but the core utilities in the current version will be there at the end, so it's not time wasted.
Me: Happy to help, now and later.

EDIT: I am already seeing problems with the code I posted (comment typos, missing fields, like category thumbnails), so I will be editing my code post. Check the "last edited" time!

[tachzusamm]

The reason I didn't create a 'users' table was because that would require a login protocol on the site, which might cause confusion (Is this the same as my GoW username? Why do I have to log in again?

Um, I assumed there will be an external server and the whole thing is not run here as a subpart ot the GoW webside and forum. And it should be available for the H'Uru guys too, because they will attend to supply with textures, models and sounds as well.

Do I have to be a writer or get permission from someone?).

That's a good question I already made some thoughts about. We should discuss, if it's better to open the server for everybody without having to register, or if we need some sort of maintaining, approval, or even a mechanism to avoid getting crap uploaded by guys trying to be funny. I don't want to decide this on my own. My only intention is to get this thing running well.


EDIT:

EDIT: I am already seeing problems with the code I posted (comment typos, missing fields, like category thumbnails), so I will be editing my code post. Check the "last edited" time!

Yes, I will check.
Regarding thumbnails: I would suggest creating them on-the-fly, rather then storing them. No need for texture-thumbnails in the database. PHP offers the ability to make some image processing, together with a glibc package (or what again was the name for this? No, I guess it was the GD library). But for categories, we do need thumbnails. Sure.
Anyway, have look at this (there may be other solutions around):
http://phpthumb.sourceforge.net/

[di gama]

The reason I didn't create a 'users' table was because that would require a login protocol on the site, which might cause confusion (Is this the same as my GoW username? Why do I have to log in again?

Um, I assumed there will be an external server and the whole thing is not run here as a subpart ot the GoW webside and forum. And it should be available for the H'Uru guys too, because they will attend to supply with textures, models and sounds as well.

What I meant from this is that although it is going to be a different server, It will (obviously) become closely related to the GoW site here (after all, we are building this server specifically to make our lives at GoW easier). It may, in fact, be possible to link this forum and the server to use the same user database, although that would mean accessing the GoW forum database directly, which means admin access (which probably isn't going to happen). As for H'uru, why (considering their line of work) aren't they part of the GoW? Is it another domain supremacy struggle? (recalling the PyPRP schism) Again, it is possible to read their user list, but I think accessing two separate databases is a bit much, even for me.

Do I have to be a writer or get permission from someone?).

That's a good question I already made some thoughts about. We should discuss, if it's better to open the server for everybody without having to register, or if we need some sort of maintaining, approval, or even a mechanism to avoid getting crap uploaded by guys trying to be funny. I don't want to decide this on my own.

Again, my only intention is to get this thing running well. I'm not trying to claim a master status for me, nor to collect privileges in maintanance, glory about the idea, reputation for making it possible, whatever. If someone got this impression.

I was under the impression that maintenance of the content was going to happen, although I don't think we should use an approval process (rather, we are just quick to remove offensive material before it does any damage). IP banning should work decently on "guys trying to be funny". The way I am trying to define my role in the project is as a code writer, nothing more. Although I have ideas about what the site should be, I have no intention of leading it. I am posting all my code for the same reason: I am not planning to be admin. *shouts to crowd* Whooooo wants to be admiiiiin? Don't make me start the nose game.

EDIT:

EDIT: I am already seeing problems with the code I posted (comment typos, missing fields, like category thumbnails), so I will be editing my code post. Check the "last edited" time!

Yes, I will check.
Regarding thumbnails: I would suggest creating them on-the-fly, rather then storing them. No need for texture-thumbnails in the database. PHP offers the ability to make some image processing, together with a glibc package (or what again was the name for this? No, I guess it was the GD library). But for categories, we do need thumbnails. Sure.
Anyway, have look at this (there may be other solutions around):
http://phpthumb.sourceforge.net/

I actually meant that the category should hold on to a link to an image, which is auto-thumbed when displayed. I just finished the relevant part of PHP code, and the way I've decided to implement it is this: if the 'image' field is not null (in use), it uses that image. Otherwise, it randomly chooses an image from among its subcategories and the images under those. If there are no usable images in the category, it displays a default image for the type. I think the random part will help 'keep it fresh,' so to speak. As for the actual PHP thumbing, it's not a problem: I wrote this a while back (I keep every scrap of code I've ever written, so I never have to write it again).

Code: Select all

<?
 $f=$_GET['img'];
 list($sw,$sh)=getimagesize($f);
 if (isset($_GET['w'])&&(!isset($_GET['h'])||($_GET['w']*$sh<=$_GET['h']*$sw)))
    list($dw,$dh)=array($_GET['w'],$_GET['w']*$sh/$sw);
 else if (isset($_GET['h']))
    list($dh,$dw)=array($_GET['h'],$_GET['h']*$sw/$sh);
 else list($dw,$dh)=array($sw,$sh);
 $src = @imagecreatefromjpeg($f)
        or die("Cannot Initialize new GD image stream");
 $dst = @imagecreatetruecolor($dw,$dh)
        or die("Cannot Initialize new GD image stream");
 imagecopyresampled($dst,$src,0,0,0,0,$dw,$dh,$sw,$sh);
 header("Content-type: image/jpg");
 imagejpeg($dst);
 imagedestroy($dst);
?>


By the way, I have designed the site, like Kosten's version, to use links almost exclusively. That means that it can hotlink to any of the large files so that we don't need much space to start up. Once we get a dedicated server, we can transfer the files to the server so that we aren't hotlinking anymore, but the capability is there, so we can start stockpiling files now. I don't know if anyone else has installed the SQL file I provided, but I have the site up for testing at http://www.faerystone.net/mario/texturu/. This is by no means the site's permanent home, but it is operational and usable (as much as possible). I am working live on it though, so I can not guarantee its operation (it's in sub-sub-alpha version right now). What I would like is a file to put into the database for proper testing (as I said, it is currently empty, so it is hard to gauge how well that part of the site is working). The protocols are not in place to add the file to the site, though, so just give me a link and I will put it directly into the database.

[tachzusamm]

Okay, I think I should stop in again. Sorry for my absence here, but the work is still in progress on my side.

I'm still writing on this requirements document, but I decided to improve my age writing and blender skills a bit first, to get a better understanding about the needs. This took a while. And I have talked to many people to get a better insight too.

A 40GB server is already ordered; I will receive the administration infos next week, and then I will try to do the first setup for LAMP, FTP, and such.

Looking at the work di gama already did, gives me hope that we will be able to implement the whole thing. Good job, man.
I understand there must be much logic and programming behind, especially for the full functionality. Looking at the currently used output "style", gave me the impression we should split design and programming, so I did some research and think we should use template techniques to accomplish this.
So, I already did some web design to get a nice user frontend, and currently I'm working out a first compilation of such a PHP/design combination, using the smarty engine. I will show some examples of the web design soon (next few hours or days, I hope).

So stay tuned, the project will continue.

What I meant from this is that although it is going to be a different server, It will (obviously) become closely related to the GoW site here (after all, we are building this server specifically to make our lives at GoW easier). It may, in fact, be possible to link this forum and the server to use the same user database, although that would mean accessing the GoW forum database directly, which means admin access (which probably isn't going to happen).

I am not aware about security holes regarding this solution, but I would really prefer to use the TextURU-server use it's own database. I understand that managing user accounts would be a big challenge (although PHP already offers some techniques like the PHPSESSID thingy), but I trust in your "eating php for breakfast" skills here.

As for H'uru, why (considering their line of work) aren't they part of the GoW? Is it another domain supremacy struggle? (recalling the PyPRP schism) Again, it is possible to read their user list, but I think accessing two separate databases is a bit much, even for me.

Most of them (especially just "photographers" without any other intentions regarding age writing) are from Germany, Austria or Switzerland and don't understand english very well so for some it's a bit hard to participate in the whole GoW part here. My first intention was to provide a multi-language interface on the server, in some parts, like user-login and categories naming.

I was under the impression that maintenance of the content was going to happen,[..]

Sure, but it would make the life of an admin much easier.

[..]although I don't think we should use an approval process (rather, we are just quick to remove offensive material before it does any damage). IP banning should work decently on "guys trying to be funny".

Most of the people I know have dynamic IPs, maybe this is different in the USA?
I'm not sure if an approval process is favored or necessary, but I still believe users should have to login before they can do any upload - and besides of that, we do need a mechanism to identify admins. Simply using FTP would work for files, but not for contents in the database; imagine how confusing it would be to *move* misplaced files together with descriptive content if your only interface is phpMyAdmin?

The way I am trying to define my role in the project is as a code writer, nothing more. Although I have ideas about what the site should be, I have no intention of leading it. I am posting all my code for the same reason: I am not planning to be admin. *shouts to crowd* Whooooo wants to be admiiiiin? Don't make me start the nose game.

When the project starts first, I could play the role of an admin, but I would appreciate if other can do this job as well - and maybe we will need moderators.

I actually meant that the category should hold on to a link to an image, which is auto-thumbed when displayed. I just finished the relevant part of PHP code, [..]

Code: Select all

[..]

Looks good.