Re: GNUstep SoftWare Index - new project home and sources of the tool

[Banlu Kemiyatorn]

On Sun, Jan 9, 2011 at 4:10 AM, Ivan Vučica <ivucica@gmail.com> wrote:
> I could not resist, I guess. Sorry, folks.
>
> 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 was just trying to be funny too by not parsing it pale face.

> 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?

If you can revert a text file I am supporting the idea. With git or
something.... Well, I change my mind I'd still stick with wiki.

>> 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?

My point was, not anyone can push php or sql right onto the hosting. A
user want an alternative field in their software index but they won't
be able to add that by herself.

>> 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.

This is also where we disagree. I think it's better to allow anyone to
manipulate your record. A user may not describe their software right,
due not to being a native English speaker or any other reasons, other
helped shaping that up, discussing with the owner and revert back to
the original description if they can't make an agreement.

>
>>
>> > 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:

No, I mean a thrid party who run free wiki hosting services I am sorry
about that Mr. tl;dr!

>
>  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.

I think Wiki bot api is quite generic and has been used intensively by
many wikipedia users not only to the hardcore one to perform several
tasks. The benefits to have someone with such experience would allow
us to maintain larger informations than just a software index but also
includes documentations, code examples and discussions etc. integrated
like you can have a software index with "What links here" and know
what people are discussing about the software etc.

>
>>
>> > 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.

That's a conflict not break. Sometimes it can merge sometimes not. But
as I told you the idea is very generic on WP. If bot detect a
conflict, it can still refetch the data and reprocess it.

>
>>
>> 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.

Defined API. If the template was well defined by the policy, then it
can be very simple.

>
> 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.

I didn't say it's hard to learn. I am familiar with web dev, I even
wrote bit torrent client with GSWeb.
Create OOP web framework with Perl, made my own webserver like..
1995?, let alone the PHP MySQL works.
What I said was it isn't hard to deal with Wiki with bot.


> (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.

I explained this point above that we can do that with existing Wiki API.

>
> 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 "Wiki" hosting. it was stated in the thread.

> * third party watching over spam (let's prevent spam in the first place),

they dealt with "Wiki" spam with their bots and spam records, automatically.

> * permitting anyone in the world to edit (or even permitting even limited
> amount of people -- both are bad since users can enter anything), and

yet another point we disagree.

> * 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.

I am okay with that. But even not fixed, it isn't still not spam. It's
like a bug that anyone if they care found it and fix.

>> 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.

I believe that if WP does, there must be that day we should be able to
have something equally right.

> 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 :-)

Point out some technical mistake. Next one I'll.

>
>
> --
> Regards,
>
> Ivan Vučica
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>



-- 
    .----.     Banlu Kemiyatorn
  /.../\...\   漫画家
 |.../  \...|  http://qstx.blogspot.com (Free Software Advocacy & Development)
 |../    \..|  http://feedbat.blogspot.com (Studio Work For Hire)
  \/      \/   http://groundzerostudiocomplex.blogspot.com (Studio Research)