2011/1/8 Banlu Kemiyatorn <[email protected]> > > And you cannot automatically have that with a dedicated tool, >
Sure you can. You have a systematized input method, and systematized presentation method. More importantly, you have an organized data structure that you can datamine (e.g. show "most active projects", "most recently updated projects" without manually updating the wiki page). > ie. you cannot do that without a plan. > Sure. Sketch out what properties are necessary before designing relational database and presentation. For example, I did that in my previous email. > You will need a plan for backup, > I'm not sure what do you mean here -- you need the same with wikis. History != backup. > corrections and ways for the others to get backup your data and source code > of the web software in case that your system went down. > What's the big deal about making nightly dumps of the SQL, sans the user account data. > For both systems, what you need is documentations. > Sure. But with dedicated, either web-based or desktop, software, you don't necessarily need to have separate documentation for simplest stuff. Like markup, or what content is required during input. You just need to present the fields and tell the user "these fields are required, this field means this, this field means that", et cetera. > > I dont see it as a pain. For many people it is even much easier than > messing with SQL. What is so hard about adding or removing properties from a > template really? How is that harder than granting rights, checking docs that > define the tables, verified the value for possible web code injections etc. > This one really depends on tastes. All I can say is I believe a dedicated database to be more systematic. Why don't wikis themselves use other wikis for storage? > > I am not against the SQL works in anyway. But I dont believe ther is an > ideal tool for anything. A database can do the job without a wiki and can > also even support the wiki process in many ways. The problem is the plan for > the maintenances I described. But if you have time and power to make it > works better then just do it. > Maintenance is an issue with wikis as well; in both cases time and will is required. Please do note that I'm looking at it this way: What will people find easier to use? What will guarantee that more people will use the system properly? What can have more consistent input and presentation without involvement of additional editors that constantly verify user input? What is more prone to spam? > where is > > the bot or the reviewer supposed to get that data from, or where is the > > bot or the reviewer supposed to place them if they don't fit into a > > template? > > In comments and post alert for needs review. > So, more eyeballs is the solution? You're counting on people's eagerness to help. If more people were so eager to help, GNUstep would be much farther along the road to Cocoa compatibility (I don't know about OpenSTEP so I can't comment on that) than it currently is. It's already quite good -- but if people were eager to give up time and help, then it would be further along. > And where do you want to place that with SQL? Just let them refill the form > sure. It's good in its way, but I dont see it better. > Doing good user input sanitization and not letting user input too much (e.g. extra markup) means user will not be able to mess things up. Simply don't let user enter random comments outside the "Developer's commentary" field. Only description serves as project description. URLs go only in the URL list. Less cleanup is needed, need for cleanup is more easily recognizable, and you can more easily verify quality of user input. For example, you can reject "%)($"'$" as project title more easily if you have a custom form than otherwise. You can also more easily require that all projects submit a description that is at least 20 words long. > And great less flexible. > Precisely. Don't trust the user to enter consistent, high-quality data. At least check the data to make sure it's at least mediocre, if not high-quality. > > Less flexible and need more security plan for community to access the host. > And if someone accidently break some records, you will need a complex > revision control method. > > You keep repeating the "less flexible" as if it is a bad thing in this case. It is not. Having a consistent, easily browsable list is preferable in case of software. Please take a look at Apple's highly successful App Store. They don't have random categories. They don't allow you to enter unlimited amount of keywords. They don't let you add software that doesn't have at least one screenshot and more than five. Even that way sometimes you get spam -- but much less if the store were to allow you to enter random data, random markup, et cetera. Not only that, but this lack of flexibility has allowed Apple to present product pages in a platform-specific way in iTunes, on iPad, on iPhone/iPod, and even preview pages on the web: on each platform, the data is presented nicely, because each field can be formatted in a platform specific way. And I do not mean just formatted: I mean placed in various native controls (listboxes, etc). Using a wiki would mean never being able to produce an installer app that allows single-click installation of a piece of software (I'm thinking of a GUI for a MacPorts-like build system). That is, never being able to do that without transferring all the data into the new system that would actually be parseable by the system. We can go on and on: you can tell me that everything can be done with a wiki (e.g. build spec file could be placed inside special tags on the wiki page or even just the build files being separately hosted, and the wiki could itself be browseable using something like embedded WebKit) -- but that's not the point. Finally, I'd like to point out that I don't have the time to focus on any such project, nor did I check out what Dr. Schaller's SWI looks like. I've just put forth my opinions on how an "app repo" could be done, and why I don't think just putting things on a wiki is the perfect solution. My opinion is that any kind of a solution is better than none, so anyone embarking on this journey with any sort of a plan in mind has my best wishes for success :-) -- Regards, Ivan Vučica
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
