Ok then, I have more ideas to that (and also I take ideas of one of TC dev, don’t remember who, I read somewhere about sniffs).
This I implemented in my own server for my friends to report bugs to me (and I forward to you), like this:
[ol][li]Have a copy of latest world DB in the target server we are using for uploading sniffs (to enable better support for later points)[/li][li]First of all, it is IMPORTANT, to have, in the upload part, a drowdown list, with the sniff area, also stored in database, this way, we can filter sniffs WAY better, and not only in the filename. All the data here can be grabAn example:Drop down 1 SNIFF TYPE: Dungeon, Exploration Zone, Questing, Item/Area trigger, NPC, OTHERDUNGEON selectedDrop down 2: DUNGEON NAME[/li][li]Drop down 3: DUNGEON DIFFICULTY[/li][/ol]
[li]EXPLORATION selected[ol]Drop down 2: CONTINENT[/li][li]Drop down 3 (depending on 1): ZONE[/li][/ol]
[li]QUESTING selected[ol](the 2 drop downs from 2)[/li][li]Min level, max level, race and class[/li][li]OPTIONAL but useful, A multi select combo box, to select the quests present in sniff (it would be a little work for uploading users, but the benefit of recording the quests is GREAT for later finding)[/li][/ol]
[li]OTHER selected[ol]A text box to put a description is added (but we need to try to avoid this, or warn the uploaders that this is the least helping option as the filtering is useless in this case)[/li][/ol]
[li]ITEM/AREA TRIGGER selected[ol]Then, display a list of items to select which item was tested, you know, there are some items which don’t work as they need scripting.[/li][/ol]
[li]NPC[ol]NPC information only, for vendors, rares, and missing loots (for example, the misterious camel figourine is missing the loot currently in TC 6.x)[/li][li]Then, display a list (or a text to find the NPC) so it can be selected.[/li][/ol]
[li]With this, we are able to completelly filter, catalog and index the sniffs to be more usable for later, instead of blindly looking, if one dev is implementing dungeon X, he can find better the data. (Way better than a forum search, or forcing the dev to index the files with good names in his own hdd)[/li][li]Are we talking about a dedicated hosting platform to host the sniff files?[ol]In this case, is the sniffer packet software opensource? (the one which handles the sniffs to see the data)In this case, we could make the uploads in zip file, read it, and replace sensitive data, like char name, account name, guild name, whispers, and the like to be like UUID numbers (to keep consistency, as this data is irrelevant for development), so <char_name> can be replaced to charname1, to guildname1 and all messages/whispers to XXXXXXX automatically once upload is finished (by calling a cgi-bin, being it implemented in PHP, or something else)[/li][li]With this method, no read protection is needed, as no sentisitive data is stored, FURTHERMORE: We can also implement something like VIEW SNIFF, which will use the wow packet software to display a list of CMSG or SMSG sent/received in a web fashion (only a summary)[/li][/ol]
[li]If not, or it is too hard to do this, then just store the files with a record in database containing the points before.[/li][li]If we can’t store them as of lack of money for a hosting or something else, then, just a basic info stored in database (the points from main 2), with the link, but this is the last prefered option, as they may get deleted later, or the hosting may fail eventually (sometimes mega for example, makes the files unavailable temporarily)[/li]I hope some of this ideas render useful for this purpose.
EDIT: I am sorry I can’t help with opcodes as I don’t have experience on them, but if you need PHP development help, or with database design, I can help with that. (HINT, if you go this way, I strongly suggest postgreSQL, as with table inheritance is way better and faster to implement the different types of sniffs)