[Wikide-l] Re: mediawiki-bausteine als navigationselemente

So Feb 29 18:23:34 UTC 2004

Ivo Köthnig wrote:

> Am Sonntag, 29. Februar 2004 06:16 schrieb Timwi:
> 
>>>Sag mal will du mich nicht verstehen oder bist du dazu unfähig?
>>
>>Bitte beruhige dich etwas. Ich bin sicher nicht unfähig, aber vielleicht
>>drückst du dich nicht klar genug aus. Du wolltest doch, daß der alte
>>Benutzername unbenutzbar wird? Also leg einfach einen unbenutzbaren
>>Account unter diesem Namen an. Was ist daran falsch?
> 
> Das Problem ist: Jemand will seinen Account-Namen ändern und alle Signaturen 
> und jedes andere Vorkommen seines Namens sollen sich mitändern! Ich glaube 
> ausser Dir ist das jedem hier klar geworden.
> 
> Du fällst ständig in einen Rechtfertigungsmodus zurück, indem du nicht dieses 
> Problem vor Augen hast, sondern nur ein Teilproblem und präsentierst eine 
> völlig unzureichende Lösung...

Nungut. Aus meiner Sicht sah es jetzt eher so aus, daß du mehrere Dinge 
zusammenwürfelst. Die Nichtverwendbarkeit eines Accounts und das Ändern 
der ganzen Signatures sind zwei separate Dinge, und ich dachte, in 
diesem "Diskussionsblock" ging es halt um ersteres.

Ich hab ja nicht gesagt, daß die "Lösung" perfekt ist. Du scheinst aber 
zu glauben, daß es immer eine perfekte Lösung gibt, und erwartest dann 
von anderen, daß sie sie für dich finden.

>>>>Wenn es zu einfach ist, seinen Benutzernamen zu ändern, dann machen die
>>>>Leute das ständig. Es ist wichtig, Benutzernamen mit Personen (bzw.
>>>>Persönlichkeiten) verbinden zu können, aber wenn die Benutzernamen sich
>>>>ständig ändern, geht das nicht mehr. Man weiß dann vorne und hinten
>>>>nicht mehr, wer wer ist.
>>>
>>>Genau deshalb habe ich ja auch gesagt, dass der alte Account einen Monat
>>>lang gesperrt bleiben soll. Das kann man ja auch leicht dahingehend
>>>ausbauen, dass der neue mindestens einen Monat bestand haben muss...
>>
>>Selbst bei nur einem neuen Namen pro Benutzer pro Monat gäbe es
>>immernoch ein heiloses Durcheinander. Bei mehr als 30 Benutzern wäre das
>>schließlich mehr als eine Namensänderung pro Tag.
> 
> Dann sind es halt 2 Monate und beim nächsten mal muss man ein halbes Jahr 
> warten. Ist deine Fanatsie so begrenzt, dass du jetzt den Zeitraum in Frage 
> stellen musst. Du solltest Wissen dass man Software an der Stelle leicht 
> anpassen kann.

Jetzt bin ich mal an der Reihe, das einen Hack zu nennen. Damit rennst 
du ja dem Problem nur davon, anstatt es zu lösen. Du denkst offenbar nur 
an die technische Möglichkeit, nicht an die sozialen Auswirkungen. Ich 
könnte also auch sagen, deine Fantasie sei zu begrenzt. Ich schlage aber 
stattdessen vor, daß wir das beide seinlassen, weil das nämlich zu 
nichts führt.

>>Ich habe eins davon gesehen (http://meta.wikipedia.org/wiki/Wikitax),
>>bin davon aber wirklich nicht sonderlich vom Hocker gerissen. Was ist so
>>sonderlich anders, wenn man statt ''...'' halt [/.../] benutzt. Kommt
>>aufs Gleiche raus. Die vorgeschlagene Syntax zum Einrücken ist Overkill
>>(wer muß schon rechts einrücken) und komplizierter als einfach ':'.
> 
> Es benutzt immer die gleiche Klammerung. Das ist leichter erlernbar.

Für einen Computerguru vielleicht. Im allgemeinen eher nicht. 
Einrückung, Fett, Links, etc. sind sowas von grundverschiedene Dinge; 
die herkömmliche (nicht-technische) Intuition sieht da wenig 
Ähnlichkeit. Dementsprechend würde ein weniger technisch orientierter 
Mensch mit den ganzen Klammern durcheinanderkommen und nicht mehr 
wissen, welche Klammer jetzt nochmal was macht.

Im Kontrast dazu ist ein * vor einer Zeile sehr viel intuitiver zur 
Erstellung von bulleted lists.

>>>Am Ende landen wir sowieso bei etwas, was ähnlich zu XML ist
>>>und wir werden nur noch logisch formatieren...
>>
>>Hm, da bin ich mal gespannt. :-) Bis dahin mache ich mal lieber mit der
>>einfachen und schnellen Wiki-Syntax weiter, hmkay? :-)
> 
> Also deine Argumentation ist lustig. Bei RDBMS, einem riesen Monster von 
> komplizierter Software (die garantiert 100erte von Bugs enthält) bestehst du 
> auf dessen Verwendung, noch dazu unter dem Performance-Argument (und nach wie 
> vor lasse ich nur das Argument des einfacheren Designs der 
> MediaWiki-Software, Datensicherheit und vielleicht gerade mal so noch 
> Skalierbarkeit gelten).
> 
> Aber wenn es um XML geht, was ja fast zu unserem Zweck erfunden wurde und 
> unter dem Gesichtspunkt der Einfachheit entwickelt wurde, da ist es dir dann 
> zu kompliziert. Noch dazu wo es schon schnelle, einfache Parser für soetwas 
> gibt, die uns die halbe Arbeit abnehmen könnten.

Ich hab überhaupt nichts gegen XML, wenn es um das maschinelle 
Verarbeiten von Daten geht. Natürlich ist es einfacher zu parsen und so. 
Aber es zerstört einen der wunderbaren Aspekte von Wiki. Ich finde * 
halt viel schneller zu tippen als <ul><li>...</li></ul>.

> Ich erkläre es auch nochmal hier: Wir haben zwar große Datenbestände, aber 
> unsere Artikel sind höchstens [... etc. etc. etc.]

Ich kann zu dem Thema ja auch einmal wiederholen, was Brion gesagt hat. 
Wenn du meinst, es geht mit Dateien (oder mit Methologie X, Y, Z) 
besser/einfacher/schneller/sauberer/etc., dann mach es. Schreib eine 
neue Wiki-Engine, oder forke die bestehende. Wenn wirklich was draus 
wird, und dein Produkt Wikipedia überzeugenderweise schneller macht als 
MediaWiki, dann wird Wikipedia das übernehmen.

Bis dahin haben wir aber nichts anderes. Also verwenden wir das, was wir 
haben.

> Wenn ihr statt SQL lieber Relationale Algebra verwenden würdet

Das kannst du ja dann bei der Gelegenheit auch mal ausprobieren. :)

Es wirft aber die Frage auf, warum alle Datenbankanwendungen unserer 
Zeit denn dann SQL verwenden :)

> Aber das Grunddesign (wozu ist welche Tabelle gut und was steht 
> drind) muss man schon erklären.

So? :-)
http://lionking.org/~timwi/t/wikipedia/wikipedia-iv.html

> Meine Erfahrung ist auch die, dass man beim 
> Schreiben einer ausfürlchen Dokumentation wie von selbst viele Schwachstellen 
> findet, weil man nochmal intensiver über sein Design/Code reflektiert.

Durchaus.

>>Ich kann dir aber wohl sagen: Die zwei Hauptprobleme, die ich mit der
>>momentanen Datenbank sehe, sind (1) die Aufteilung in 'cur' und 'old',
>>und (2) viel zu häufige Verwendung von Textdatentypen (VARCHAR und
>>BLOB), wenn Ganzzahlen (INT) ausreichen. Brions Vorschlag löst nur das
>>erste.
> 
> Die Trennung von cur und old hat zumindest den Vorteil, dass cur klein ist und 
> man das noch runterladen kann. :-).

Ja. Das war wohl der ursprüngliche Grund dafür.

> Aber im Bedarfsfall sollte eine einfache 
> SQL-Abfrage auch eine Cur-Tabelle generieren können.

Eben.

Timwi