On Sat, Jan 8, 2011 at 21:15, Banlu Kemiyatorn
<object@gmail.com> wrote:
I felt it's important to make it clear what
you think, not why you are right or why you aren't wrong. Because the
process of reasoning could help developing the conclusion for the
others in future.
This is a bit offtopic discussion for this list, that's all. "discuss-gnustep", not "discuss-storage".
>> As long as you sacrifice the flexibilities.
>
> Flexibility is not sacred.
> Let's keep everything in a text file, shall we?
Why do you think text file is more flexible than a wiki?
I guess I should make use of more <sarcasm> tags :-)
I tried to be funny. Text file is a simpler storage engine, just like storing stuff in a wiki would be. Why bother with organization and ability to more easily extract, filter and sort data if we can simply store everything in a CSV text file?
> I have no idea. Why do you want a wiki to describe entities with properties?
> :)
For instance, it's more extensible by anyone without access to the php
code or sql by practice.
Why would one want to open up a database to everyone? One thing is providing dumps, quite another providing direct and complete control to everyone.
Why can't everyone perform a hg push or a svn commit in every single project in the world?
If you open a connection to SQL server to
manipulate entries, how would you log or revert bad changes?
It's called backup, and it's called... logging. :-)
It is definitely harder. But, it is better to vet user input in the first place than to react.
> If you can find people uninterested in GNUstep to truly maintain a GNUstep
> software index, that's excellent :-)
Well, just maintain the Wiki. Software index still need man hours.
ie. SQL + PHP > Wiki (maintained by third party) + PHP
Wiki is not maintained by third party, it's hosted and its core software is written by a third party. We can alternatively put it like this:
SQL (hosted by third party) + PHP <=> Wiki (hosted by third party) + PHP
You yourself have (below) suggested writing a form-to-wiki interface. What's the benefit of studying wiki's database and/or studying wiki's API, and parsing large strings containing our data (converting them into structures we can update and write back), all while being careful not to overwrite anything in case a user has managed to mess up syntax somewhere and we don't quite handle that case.
> You mean like an external link to a wiki page? Agreed, having a secondary
> presentation is good. After a user finds the program, then getting more info
> about it is important!
No, what I meant was a PHP hosted on gnustep.org submitting record via
wiki bot API to a wiki + extensions bots don't understand but will
just leave them alone.
As explained above, you're advocating assembling a Rube Goldberg machine that can break while parsing user input and writing it back.
I am sticking with
SQL + PHP > Wiki (maintained by third party) + PHP
But if PHP->Wiki bot needs more time for the maintainer to learn than
PHP->SQL then I'd also minus the invaluable benefit of the system
being more open to community to the left side and weight again. Must
find another invaluable factor on the right side.
How would the bot communicate with the wiki? Touching the database directly? Using some API? Whatever it will do, it probably isn't as simple to access the data as it is to access an SQL database from PHP or other language/framework, and perform a query.
Sorry to put it this way, and doubly sorry if I am incorrect -- but your statements about PHP+SQL being hard to learn and maintain tell me you have not spent a lot of time writing simple and/or complex content management systems.
(Un)fortunately, I have -- and I have also spent a certain amount of time extracting data from various unstructured raw strings that were provided to me, I spent some time messing around with web APIs, etc etc, and I can practically assure you that attempting to remotely update wiki pages that could have been customized by a user will result in a lot more stress, work and long-term maintenance work than you seem to think.
Again, if you are talking from experience, then obviously I am the one lacking it -- and I apologize. But, this is how it seems to me: that you incorrectly believe that values such as:
* third party hosting (what's wrong with servers like
gnustep.org?),
* third party watching over spam (let's prevent spam in the first place),
* permitting anyone in the world to edit (or even permitting even limited amount of people -- both are bad since users can enter anything), and
* having wiki software solve content versioning,
outweight the issues of:
* parsing user input to extract and update valuable data
* communicating with remote third party server using volatile API
I'd just revert the change. Inform them about the PHP front end we
have prepared or just let them edit again.
And you'd never hear from probably 30-40% of them again. Others would bitterly go and read the documentation, but do so unhappily. Then you'd get a submission.
Please look at StackOverflow and Ohloh, and see how the documentation can be done right next to the form. Of course, since you want the form to talk to the wiki upon user clicking "Submit", you'd tell me that you can do that anyway.
On the other hand, when talking just about the wiki, you'd have bad submissions until you revert -- and perhaps never get the fixed ones, and that's the context in which I originally posted.
> What I see is that customers enjoy it enough to be willing to even fork over
> the money and the freedom. Increasing user satisfaction and bettering his
> experience does not mean we have to take away his freedom, or vice versa.
> Besides, you're deliberately diverting the subject to the importance of
> freedom, which is not discussed here, and which is something I agree with
> you on. (Mostly.)
My point was that user should maintain their freedom by being allowed
to do whatever they wish and learn the consequence rather by being
stop to experience, like appending too many tags.
Oh, you're a cookie :-)
But seriously now, appending tags in the context of submitting applications of App Store:
Some segments of even human-reviewed App Store are spammed with applications already... and I'm pointing out that we have paid human reviewers who have a reputation for being too strict.
Not allowing unlimited amount of tags means app developers cannot spam the search engine with too many tags, and forces them to keep them relevant.
On the subject of customers' freedom, well now, people voted for user experience of user freedom.
Now really, send me the next reply in private :-)