Thread: [Boardmod-devel] passed discussions
Brought to you by:
michaelprager,
t-master
From: [CV]XXL <X_...@gm...> - 2002-09-30 21:34:51
|
Here is a collection of passed discussion mails which could not be archived. Start reading from the bottom! Newer mails are on the top. Each mail is seperated by a [ snip ] line. I couldn't check each mail but that should be bretty much everything which has been discussed. ====== [ snip ] ============================================== I suppose. Yeah, I think that might also work. -----Original Message----- From: [CV]XXL [mailto:X_...@gm...] Sent: Sunday, June 23, 2002 5:36 PM To: yab...@ap... Subject: Re: Boardmod 3 and YSE2 Pacman Hm I think a <chmod> tag would fit best into the mod structure. At the moment, everything is based on the <edit file> tag. e.g. + edit file - search... - replace... - anything else todo with that file + edit another file - search... - replace... - anything else todo with that file adding a <chmod> tag which is dependend from a previous <edit file> would make sence here. ====== [ snip ] ============================================== well, since it is only applicable to one file, usu. the file being edited, attributes would be best. I can understand this is pretty hard to implent into boardmod, so we might have to think of another way. I don't like the <chmod> though, since it is still reffering to the same file as that is being edited. -----Original Message----- From: [CV]XXL [mailto:X_...@gm...] Sent: Sunday, June 23, 2002 4:06 PM To: yab...@ap... Subject: Re: Boardmod 3 and YSE2 Pacman >> I also have somne suggestions for the <file> tag. I think it should have >> attributes as such: <edit file name="$filename" chmod="$permissions" >> chown="$owner">$filepath</file> That should also help since modders won't >> have to ask for users to chmod their files any more. > > I suggest to keep it as simple as possible, means that we try to only use one tag for one action. I suggest a <chmod> and a <chown> tag but not to touch the <file> tag. Also people don't have to set the rights of a file to just open it. It would not be a problem to get attributes working from the programmer point of view but it would make thinks more complicated for mod writers too. About the gzip/zip thing: I don't know what's better and what would be simpler to code but I know that almost everybody knows what todo with a .zip file but only a very few know what todo with a tar.gz file. I like your idea of a <guid> tag too. It would also be handy if only we would be able to generate such a guid number because then, others would not be able to "fake" a mod as approved. Michael Rodriguez-Torrent schrieb: >>Yea, tar+gzip should be fine, but I was thinking that just plain zip might >>be better, because it only involves one operation (zip) instead of two (tar >>and then gzip). Zips are actually very easy to create in PHP, Jeff pointed >>me to a good article about it. See here: >>http://www.zend.com/zend/spotlight/creating-zip-files1.php. AFAIK, the >>current version of PHP has no more zip support than previous versions. The >>code in the article creates much of the zip file manually. >> >>If we decide to go with tar+gzip, a little while back I found a few tar >>libraries: >>http://phpconcept.free.fr/pcltar-index.en.php3 >>http://pear.php.net/package-info.php?pacid=24 >>IBForum (invisionboard.com) also has a "tar.php," but the board's license >>doesn't allow anyone else to take and use the file, because they're not >>using an open source license. Losers. Oh, just FYI: gunzip isn't another >>file type, it's just the unix command used to decompress gzip files. ;) >> >>The idea of attributes for a tag is something I've mentioned before, but I >>don't think T-master or XXL have responded as to whether they will be able >>to do that in BoardMod, so we'll see. The Perl/PHP regex for parsing these >>will be rather interesting, as well... >> >>I like your reasoning behind the .list files. If the database is down, then >>PacMan won't be accessible (because it won't be able to check in the >>database if you're an admin), but BoardMod will still be able to retrieve >>the .list file so you can work on your site. Very cool. =) >> >>About the mod review script, it's not that undeveloped, because the whole >>database layout is essentially done. All I need to know from you all is > > what >>information you want to be able to pull from the mod review script and in >>what format it should be. This is how I imagine it will work: >>1) The user goes to PacMan or BoardMod, clicks an "install new mods" >>link/button. >>2) PacMan/BoardMod call the mod review script, which sends them the list of >>categories, and PacMan/BoardMod display the categories to the user. One >>category can be "local mods" (mods stored in the "mods" folder on the > > server >>(PacMan) or on the user's hard disk (BoardMod)) >>3) The user clicks on one of the categories, PacMan/BoardMod query the >>script again and get a list of mod titles in that category. >>4) The user clicks on a mod, the script is queried to get the mod details >>(author, description, etc.) as well as the location of the file. >>5) User clicks "download & install," PacMan/BoardMod use the location >>already sent to pull the file. They can have the option to install with >>compatibility checking (see next step) or without. This should be ON by >>default, and put a note that says "HIGHLY RECOMMENDED". >>6) If compatibility checking is selected, PM/BM run through the mod file, >>open all the files that need to be changed, and check to see that all the >>search strings are there. >>7) If they're all found, continue to next step. If not, generate a BIG >>warning, but give the user the option to continue anyway. >>8) Make the changes and add the GUID (from the mod database) to the .list >>file. >> >>Some other things I'd like to see: >> - A good idea that I mentioned previously was that we could store an md5 >>checksum of a mod when it is uploaded to the mod database. This way, we can >>add a <guid> tag to mods. When someone gets a mod, first the script will >>check for a GUID. If it doesn't have one, it warns that this is an >>UNREGISTERED, UNAPPROVED mod and potentially DANGEROUS. If it has one, it >>queries the mod database to get the md5 checksum of the mod with that GUID, >>then makes a checksum of the file it has locally, and compares them. If > > they >>differ, it generates some similar warning, perhaps saying the mod is trying >>to pretend to be something it's not. It also checks with the mod database > > to >>see if the mod is approved, rejected, or hasn't been reviewed. If it's >>anything other than approved, it generates a warning. >> - Something else I've mentioned before was that the calls to the script > > can >>be cached by BoardMod and PacMan. Once they get information from a > > category, >>for example, it can be saved in a local file. The next time the user goes > > to >>the same category, BM/PM compare the date of the file to a "last date of >>change" from the mod review script. If the file has the same or newer date, >>the mod script doesn't get queried again, which would save time, bandwidth, >>etc. >> >>Phew, okay, I think that's it! >> >>Michael >> >> >> >>-----Original Message----- >>From: Floris P. Barthel [mailto:mep...@em...] >>Sent: Sunday, June 23, 2002 8:25 AM >>To: yab...@ap... >>Subject: Boardmod 3 and YSE2 Pacman >> >> >>Hey guys, I'm Floris Barthel and Jeff asked me to create the pacman for >>YSE2. Before I start off, I want to make sure with all the YaBB, Boardmod, >>and YaBB Se will use the same tags. I read in one of the messages that the >>YSE 1 tags should be garbaged and the boardmod tags used instead. I agree >>with that for two reasons: >>- Boardmod tags are easier and more selfexpanatory >>- Boardmod tags are better known among modders >> >>I also have somne suggestions for the <file> tag. I think it should have >>attributes as such: <edit file name="$filename" chmod="$permissions" >>chown="$owner">$filepath</file> That should also help since modders won't >>have to ask for users to chmod their files any more. >> >>For compression I suggest tar + ZLIB (either gunzip or gzip since both are >>fully supported by php). I don't suggest zip, since olders versions of php >>still have experimental zip support. >> >>I think downloaded mods should be stored in .list files for both yse and >>yabb since if the database stops responding and you don't have a recent >>backup, it might claim the mod as uninstalled while it really is. the .list >>files should also use tags to identify the parts. .list files should be >>given full permissions so you can use boardmod to update boardmod database >>or visa versa. >> >>I am unsure about how boarmod and pakman should handle the mod review > > script>since the review script is still in it's infant stages.> >~Mephid ====== [ snip ] ============================================== Perhaps we could put a new tag into boardmod, so we could have the info on who wrote it, > > and then a new <IsUserModule=true> tag, which would just have to be there and we > > wouldn't make any source mods. > hm... for modules perhaps a new filetyp would be better? > so users can know there's a difference. > or how do u mean how has the modfile to view like? Well, i just want mod writers to be able to get credit. I guess I just want mods to be registered if they are modules, so that I can keep track of them >>> > We also wish to have some files not edited by mod writers. I do not know which files yet, but >>> > they will be files like YaBB.pl, DBInterface.pm, yCGI.pm, Template.pm. We need to figure out >>> > how to lock those files. >> >> >> how do u want to lock them realy? i don't know how @the moment. >> perhaps we can add a filelist to bm so bm will not change these files - it'll show an error message. > > Yeah, that will work, we just don't want these files modified except by YaBB itself >>> > To add settings, we can no longer add them to a file and be done. >>> > I propose the <addSetting> (or something like it tag) >>> > <addSetting>settingsname::setting init value</addSetting> >> >> >> then a <addLanguageText> would be nice too. but the danger is that we'll have too much tags in the end :-/ this could confuse the ppl... > > Well, it could confuse people, but they can still write mods the old way, the only things that are changing really are the PHP-Nuke like modules are regstered as modules. Settings, new operations in YaBB.pl, and language tags must be added via tags, and its really not that hard. These tags are much simpler than the mods 9/10 times -- Matt Sie...@ma...http://www.mattsiegman.com ====== [ snip ] ============================================== I propose an SQL tag, it can add fields to the database, and the deleteable update.pl file will > execute it. I don't know how well iot would work however, as each query must be submitted > seperately, so possibly, one query per <sql> tag k will work i think >>We want to allow people to not have to modify code to add modules, much like PHP-Nuke. > > very could idea! modules would make YaBB more clearly. >> Perhaps we could put a new tag into boardmod, so we could have the info on who wrote it, >> and then a new <IsUserModule=true> tag, which would just have to be there and we >> wouldn't make any source mods. > > hm... for modules perhaps a new filetyp would be better? so users can know there's a difference. or how do u mean how has the modfile to view like? >> We also wish to have some files not edited by mod writers. I do not know which files yet, but >> they will be files like YaBB.pl, DBInterface.pm, yCGI.pm, Template.pm. We need to figure out >> how to lock those files. > > how do u want to lock them realy? i don't know how @the moment. perhaps we can add a filelist to bm so bm will not change these files - it'll show an error message. >> To add settings, we can no longer add them to a file and be done. >> I propose the <addSetting> (or something like it tag) >> <addSetting>settingsname::setting init value</addSetting> > > then a <addLanguageText> would be nice too. but the danger is that we'll have too much tags in the end :-/ this could confuse the ppl... T-Master ====== [ snip ] ============================================== Those are great ideas. I propose an SQL tag, it can add fields to the database, and the deleteable update.pl file will execute it. I don't know how well iot would work however, as each query must be submitted seperately, so possibly, one query per <sql> tag Also, I want to emphasize that YaBB 2 will possibly have many APIs and stuff so people can write a calendar mod without modifying __ANY__ code at all. We want to allow people to not have to modify code to add modules, much like PHP-Nuke. Some of these could be a calendar, a news module, etc. There will be a difference between mods and new modules. If it is a new module, all that we will need to do is extract file and put them into a UserModules directory or something. Perhaps we could put a new tag into boardmod, so we could have the info on who wrote it, and then a new <IsUserModule=true> tag, which would just have to be there and we wouldn't make any source mods. We also wish to have some files not edited by mod writers. I do not know which files yet, but they will be files like YaBB.pl, DBInterface.pm, yCGI.pm, Template.pm. We need to figure out how to lock those files. To add settings, we can no longer add them to a file and be done. I propose the <addSetting> (or something like it tag) <addSetting>settingsname::setting init value</addSetting> I'm sure I will come up with more eventually. ====== [ snip ] ============================================== shit, shit, shit! had probs with sending the mail and so i used the "back"-button from the ie and i put only matt's email adress in the adress field :-/ ...sry... here it is: "Torsten Mrotz" <t-m...@we...> schrieb am 12.06.02 21:55:28: >>> >linux distributions also. The problem is when people do not have gzip installed. That is a >good time for boardmod :) >> >> >> *g* yep >> >> > > >>> > o We should use the current .mod file format, give me the list of every possible tag, and I'll put them into pacman >> >> >> >> hm... k i'll start with currently integrated ones: >> >> - <id> : Modname >> - <version> : Modversion >> - <mod info> : Moddescription >> - <author> : Modauthor or author(s) >> - <homepage> : Homepage(s) from Modauthor >> - <edit file> : let's BM open a file to edit >> - <search for> : BM searches for the following string ( probs with tabulators, line breaks and hidden characters if a mod writer hadn't payed attention to that ... :-/ ) >> - <add after> : adds the following string behind the searched string ( first u have to use the search tag after that u use the other "text-editing"-tags >> - <add before> : writes the following string before the searched string >> - <replace> : replaces the searched string >> >> >> all tags are closed with </tagname> >> >> >> i have some ideas for new tags which COULD be useful - your ideas are asked! >> >> - title tag for code blocks so u can say this part of code is for doing this and this... or something like a comment-tag >> - "modexists"-tag ... don't want to explain cause you will know what i mean if you look [url=http://boardmod.yabbforum.com/yabb/YaBB.pl?board=freeforall;action=display;num=994461095;start=15]here[/url] reply #28 and following >> - <add between> - tag; see the same post as above. we decided originally to forget this idea cause there are too many mods so perhaps the files will get longer and longer >> - perhaps a "<upload>$yabbdir/Sources/MyMod.pl 666</upload>" tag... xxl mentioned this a long time ago. this tag would upload a specified file with the correct chmod. but perhaps we don't need it cause bm will manage a list with file endings and in which format bm will try to upload them ( list will be easily editable ) >> - language tag in which is defined for which language there are patches. a user could choose in bm a standard language so that bm could search for the language patch and automatically execute it >> ex: >> [lng] >> english=moderatorforum_eng_patch >> german=moderatorforum_ger_p atch >> french=moderatorforum_fren_patch >> [/lng] >> >> hm... i had more and better ideas but i can't remember :-/ >> however - what do u think? >> >> >> Bye T-Master > > ====== [ snip ] ============================================== > > > o We have to use gzip format. Just about every Win*** can read it. > It is standard with most linux distributions also. The problem is > when people do not have gzip installed. That is a good time for > boardmod :) > > Oh didn't know that even winzip can read it... cool :-) We only have to make sure that we get a library for delphi which can read those too. > o We should use the current .mod file format, give me the list of > every possible tag, and I'll put them into pacman > > I attached the howto.txt from the boardmod package. It contains all definitions about the *old* .mod format. However I would like to break a rule for the new one: <search for>This mod changes nothing</search for> this is not allowed in the current mod format. however it would allow us to increase the possiblities a lot. We would let the program search for EVERYTHING between the <search for> and the </search for> tag and no longer only all lines between them. That way the following code would still work as well: <search for> This mod changes nothing </search for> The line above would search for a line, not for the "word" itself. Reason are the two breaks (before and after the "word"). So people can still use it as they always used it but they would also have the possibility to search for things smaller than a textline. Torsten and I also suggest to introduce some additonal tags. For example an <upload> tag as well as an <chmod> one. We still have to speack about its details though... > ---000 APIs 000----- > Here is how things will work: > > you call a URL, something like > http://somesite/yabb2/modules/pacapi.pl > This will post the query, and will send any other neccessary data. > You should be able to do that, since you hopefully will have full > control of your HTTP communications. > > Hopefully, I can elaborate on this more in the near future, but I need > to start coding before i can be exact about those things. > > > ------------------------------------------------------------------------ ------------------------------------------------------------------------- This file handles the question how to write a mod file without Mod Editor ------------------------------------------------------------------------- 1. The Basics 2. Example of a .mod file 3. How to remove a line 4. How the 'uninstall' function works 1. The Basics ------------- The .mod file is a plain ASCII text file and looks a bit like HTML code. When you have created a .mod file, copy it into the 'Mod' folder. There are 10 different expressions: <ID> this is the mod name <Version> mod version <Mod info> the mod description, can be longer than one line <Author> the mod author, only one line <Homepage> the author's homepage, only one line <Edit file> a file within to search and edit <Search for> one or more lines to search for in the file specified before with <Edit file> <Add before> adds one or more lines before those which had been searched <Replace> replaces the searched line/lines by one or more <Add after> adds one or more lines after those which had been searched Every expression is a bracket surrounding something. So for example <ID> This mod changes nothing </ID> or <Edit file> Sources/display.pl </Edit file> Please note the breaks after <ID> and <Edit file> and before </ID> and </Edit file>. So, DON'T write like this: <ID>This mod changes nothing</ID> The following expressions allow multiple lines: <Mod info> <Search for> <Add before> <Replace> <Add after> example: <Mod info> This is a very long description for a simple mod. Isn't it? </Mod info> 2. Example of a .mod file ------------------------- Here is a complete example of a .mod file: ------------------start example.mod---------------------- <ID> Example Mod v1.0 </ID> <version> 0.1 Alpha </version> <Mod info> This is an example mod to demonstrate the possibilities of this program. Please note that this mod is NOT made to be applied to a YaBB mod. It's just an example! </Mod info> <author> Mr.X </author> <homepage> http://www.mr_x.com </homepage> <Edit file> Sources\Display.pl </Edit file> <Search for> if($signature ne "") { $signature = "<br>-----------------<br>$signature"; } </Search for> <Replace> if($memset[5] eq "\n"){ $signature= ""; } else { $signature= "<hr size=1 noshade width=40\% align=left>$signature"; } </Replace> <Search for> $signature= "<hr size=1 noshade width=40\% align=left>$signature"; </Search for> <Add before> #Example modification </Add before> ////////////////////////////////////////////////////////////////////////////////////// Outside the brackets you can write what you want! The program will skip this lines... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ <Edit file> Sources\ModifyMessage.pl </Edit file> <Search for> print FILE "$subject\|$mname[$x]\|$memail[$x]\|$date\|$musername[$x]\|$icon\|0\|$ENV{REMOTE_ADDR}\|$message\n"; </Search for> <Add after> $dpmsgs[$dpmsgsc] = "$dpthreadb|$dpsub|$dprn|$dpem|$date|$dprc|$dpun|$dpic|$dpuk\n"; open(TN, ">$boardsdir/$currentboard.txt"); &lock(TN); </Add after> ---------------end example.mod------------------------ Please note that the lines to search for must be EXACTLY like the lines within the .pl file! So, if there are 5 spaces at the beginning of a line, these spaces must also occur in the <Search for> statement! For more examples see the .mod files included in this archive. 3. How to remove a line ----------------------- When you want that the program removes a line in a .pl file, it is NOT allowed to write <replace> <replace> or <replace> </replace> But you can reach the same by a little trick: add the line before to the empty one. Example: <Search for> $message <div align=right><img src="$imagesdir/ip.gif" border=0 align=top> $ip</div> </Search for> <replace> $message </replace> 4. How the 'uninstall' function works ------------------------------------- The 'uninstall' function goes the mod file backwards. That means that a <search for> a <replace> tag are reversed. Example: <search for> lalala <search for> <replace> hehehe </replace> The Uninstall funktion uses it like this: <search for> hehehe <search for> <replace> lalala </replace> <Add before/after> tags will just be removed ====== [ snip ] ============================================== ---000 File Formats 000--- OK, we should use one file format. There are a few thingss that we really need though for this to work. o We have to use gzip format. Just about every Win*** can read it. It is standard with most linux distributions also. The problem is when people do not have gzip installed. That is a good time for boardmod :) o We should be able to include Source, Graphic, whatever files in the GZip package. o We should use the current .mod file format, give me the list of every possible tag, and I'll put them into pacman ---000 APIs 000----- Here is how things will work: you call a URL, something like http://somesite/yabb2/modules/pacapi.pl This will post the query, and will send any other neccessary data. You should be able to do that, since you hopefully will have full control of your HTTP communications. Hopefully, I can elaborate on this more in the near future, but I need to start coding before i can be exact about those things. -- Matt Siegman web...@ma... http://www.mattsiegman.com ====== [ snip ] ============================================== k here i'm guys :) HI you three! MOD IDENTIFICATION: I agree. We should use the ModID created by adding to the mod database. for unregistered mods we should reserve the id "0". if boardmod gets the list and a mod has the id 0 it'll display an information that it isn't registered, yet. if bm wants to install an unregistered mod it'll display a warning, too. MOD LIST: don't know much about pacman but will it show all installed mods?? then pacman has to know what mods were installed with bm and bm has to send a mod-list to pacman, too. bm can easily call the script with a command which says "hey show me your installed mods list" ;) to the list which bm should get... it doesn't relay matter which the format will be but here's the easiest idea: simply let the script output a html page which displays the mods and all their information an a table. bm will choose what it needs ;) FILE FORMAT (.mod, .yp) i don't like the idea to use 2 different file formats. you'll confuse the ppl. we are'nt a software company which invents new file formats, ofte, to make more profit! i think we should all use ONE format. why i prefer a format like BM uses (zip-package with mod-file) instead of the Pacman format: only readable with packman and later with bm. no one can do the installation by hand! this is f.ex. often asked cause there isn't yet ( and perhaps never will be ) a boardmod version for all OS or the mod file can't be installed with the program. i also think it's nicer cause everyone can easy see what all belongs to that mod (*.jpg's, *wav's, etc. ) so they can easily exchange the files if they want. to the .mod files themselves: the current mod files for bm aren't best, i know. we should think about new and better "tags" and/or ways to save the commands. COMPRESSING Modfiles torrent wrote: >>Maybe make >>PacMan support Gzip, and if their server doesn't have it, tell them to go >>download BoardMod, which would uncompress the files for them. > > i agree and yep we should use the zip-format. it's used often and "everyone" knows it. >> This is assuming XXL & T-master can get a library to zip/unzip files, of course > > and XXL wrote: >>I also agree that mods should be comressed with zip or gzip, I was >>already thinking about a .zip support for 3.0. > > yep i also thought about it and used .zip-components for delhpi in my own little programs. but i don't know how many are 4free and so easy to use. we'll see but i think BM3.0 will handle .zip files. MYSQL PORT >>Another thing I could put is the ability for BoardMod3 to execute MySQL queries through this >API. > > as mentioned - no... FTP is much better. ENCRYPTION OF TRANSMISSIONS between Pacman and BM >>All these transmission should be encrypted in some scheme that can be decoded, or at least >the password during the transmission > > as mentioned, too - no... so that were my 2 cents hope to see it working soon ;)) Greetings Torsten aka T-Master ====== [ snip ] ============================================== YPs don't actually compress them. I was thinking we could use GZip, but not all servers have it, and you guys would have to find a DLL. Any Ideas? Hm, not atm. Don't the majority of servers have Gzip, though? Maybe make PacMan support Gzip, and if their server doesn't have it, tell them to go download BoardMod, which would uncompress the files for them. This is assuming XXL & T-master can get a library to zip/unzip files, of course. >>>> I don't get what your saying. PacMan will maintain some sort of list, >> >> somewhere, and all BoardMod should have to do is call up PacMan and ask for a list. Okay, great. I thought you were saying that you wanted BoardMod to send PacMan a list of installed mods, instead of vice versa - "I also would like BoardMod 3 to be able to send lists of mods it has installed to a board." Michael ====== [ snip ] ============================================== Okay, I personally don't need anything from PacMan. What I do need from you, > however, is what exactly you want the mod review script to output in order > to allow PacMan to display a list of mods available for download and then to > download and use them. I will be working on that soon. It will either be an XMLesque file, or a YaBB SE style file. >> This could be taken from the mod's "modid" number in the mod database. We'd >> have to figure out some way to deal with "unregistered" mods, however. > > We'd just put a warning of incompatibility if it is unregistered and say that some features may be affected. >>>> >> I will also give you the file format of Yabb Packages (.yp) so that you >>> >>> >> could write support into BoardMod 3. >> Is there some way we could agree on a single compression format such that >> all users will have easy access to compress/decompress the file? Maybe the >> YP's would be the best solution, if both PacMan and BoardMod will be able to >> compress/decompress them. > > YPs don't actually compress them. I was thinking we could use GZip, but not all servers have it, and you guys would have to find a DLL. Any Ideas? >>>> >> I also would like BoardMod 3 to be able to send lists of mods it has >>> >>> >> installed to a board and possibly be able to upload YaBB Packages so they >> could be installed on the board. >> Hm, I think this should be kept server-side, with the GUID, instead of the >> current method of keeping a text log of installations, don't you? > > I don't get what your saying. PacMan will maintain some sort of list, somewhere, and all BoardMod should have to do is call up PacMan and ask for a list. >> >> Ergh, a big no-no, I'd say. As I mentioned, I think the whole idea of >> creating an external access point is just bad from the start - especially >> when BoardMod 3 will have FTP support. Maybe BoardMod could generate an >> "Update.pl" file for each installation that would have a hook somewhere in >> the main Y2 program, so that it if found, it would be run and then deleted. >> It would be more secure this way, because the file could only get there via >> an FTP transfer by the user/BoardMod. > > Ok, your idea is better. And safer >> >> Well, my position is that the only things that should be transmitted are >> mod lists/details, which don't need to be encrypted. Besides this, the only >> encryptions that you know will be on every system (i.e. crypt()) are >> one-way, and I think it would be overkill to get into PKI or PGP or >> something in order to transmit mod lists. Let's just leave it open, it >> shouldn't compromise security in any way, even if intercepted. > > OK, agreed. >> >> Let's get this show on the road! ;-) >> >> - Michael > ====== [ snip ] ============================================== Hey stranger! =P Okay, I personally don't need anything from PacMan. What I do need from you, however, is what exactly you want the mod review script to output in order to allow PacMan to display a list of mods available for download and then to download and use them. >>>> To make it work, each mod would need a unique GUID type identifier or >> >> something so that we could keep track of them even if the name changes. This could be taken from the mod's "modid" number in the mod database. We'd have to figure out some way to deal with "unregistered" mods, however. >>>> I will also give you the file format of Yabb Packages (.yp) so that you >> >> could write support into BoardMod 3. Is there some way we could agree on a single compression format such that all users will have easy access to compress/decompress the file? Maybe the YP's would be the best solution, if both PacMan and BoardMod will be able to compress/decompress them. >>>> I also would like BoardMod 3 to be able to send lists of mods it has >> >> installed to a board and possibly be able to upload YaBB Packages so they could be installed on the board. Hm, I think this should be kept server-side, with the GUID, instead of the current method of keeping a text log of installations, don't you? >>>> Another thing I could put is the ability for BoardMod3 to execute MySQL >> >> queries through this API. Ergh, a big no-no, I'd say. As I mentioned, I think the whole idea of creating an external access point is just bad from the start - especially when BoardMod 3 will have FTP support. Maybe BoardMod could generate an "Update.pl" file for each installation that would have a hook somewhere in the main Y2 program, so that it if found, it would be run and then deleted. It would be more secure this way, because the file could only get there via an FTP transfer by the user/BoardMod. >>>> All these transmission should be encrypted in some scheme that can be >> >> decoded, or at least the password during the transmission. Well, my position is that the only things that should be transmitted are mod lists/details, which don't need to be encrypted. Besides this, the only encryptions that you know will be on every system (i.e. crypt()) are one-way, and I think it would be overkill to get into PKI or PGP or something in order to transmit mod lists. Let's just leave it open, it shouldn't compromise security in any way, even if intercepted. Let's get this show on the road! ;-)- Michael ====== [ snip ] ============================================== Hi, this is Matt Siegman. I'm on the YaBB 2 Dev Team. I want to talk to you about BoardMod3 and YaBB2 PacMan (Package Manager) compatibility. Its a bit important. I am planning to write some APIs into YaBB2's Package Manager. I was wondering what would be helpful to you guys. I was hoping to at least write a function for you to access a list of mods installed by the PacMan. To make it work, each mod would need a unique GUID type identifier or something so that we could keep track of them even if the name changes. I will also give you the file format of Yabb Packages (.yp) so that you could write support into BoardMod 3. I also would like BoardMod 3 to be able to send lists of mods it has installed to a board and possibly be able to upload YaBB Packages so they could be installed on the board. Another thing I could put is the ability for BoardMod3 to execute MySQL queries through this API. All these transmission should be encrypted in some scheme that can be decoded, or at least the password during the transmission. Please get back to me soon, as I really need to get started on the PacMan. -- Matt Siegman web...@ma... http://www.mattsiegman.com |