[linux-l] Re: belug lernt nicht dazu!

Sa Nov 26 22:07:55 CET 2005

On Sat, Nov 26, 2005 at 05:31:41PM +0100, Volker Grabsch wrote:
> On Wed, Nov 23, 2005 at 01:10:49PM +0100, Oliver Bandel wrote:
> > [...]
> > > > Aber sie sind IMHO oftmals zu aufwendig.
> > > > Klar, besser als HTML schon. Aber was sagt das schon?
> > > 
> > > "oftmals", schon wieder so ein schwammiges Wort. Warum pauschalisierst
> > > du über alle Wikis?
> > 
> > Gut: also bei den Wikis, die mir begegnet sind fand ich meistens
> > keine sehr bequeme benutzung.
> > Ich habe mir aber nicht immer gemerkt, _welche_ Wiki-SW dahinter steht.
> 
> Ja, aber das macht dein Argument auch nicht besser. Immerhin sind
> Wikisprachen bisher das beste, was wir haben.

mag sein.

> Sicher werden nicht
> alle Syntaxdetails jedem gefallen. Aber das ist Geschmackssache,
> bisher waren alle Wikisprachen, die ich gesehen habe, gleichermaßen
> "einfach" bzw. "schwer". Aber zu den Sprachen weiter unten.

Vieleich wäre dann eine nutzerspezifische Syntax das richtige. :)

> 
> Falls du mit "unbequemer Benutzung" auch die Wiki-Weboberflächen
> meinst: die standen für mich gar nicht so im Vordergrund, da ich
> sie ohnehin nur als "zusätzliche Option" zu den im SVN gelagerten
> Wiki-Textdateien vorschlug.

SVN?

> 
> Um die Diskussion mal voran zu bringen: Wie sollte deiner Meinung
> nach eine Wiki-GUI aussehen?

Schwer zu beschreiben.
Wenig schnickschnak, aber einfache und powervoille Bedienung.

Mit ist übrigens eingefallen, daß ich letztens einen
Wiki mal bei jemanden in einer Firma in Aktion sah,
der mit ein paar wenigen Klicks und dann eintippen
der Texte alles fertig stellen konnte.
Ohne langes suchen nach den passenden Links.
Hätte mal nachfragen sollen, was für ein Teil das war.
Wer weiß, vielleicht war das ja reST-basiert?

Das fand ich erstaunlich schnuckelig. :)

> Was sollte man an den Weboberflächen
> verbessern? Ist SVN eine gute Alternative?

Kenne ich nicht. Für was steht SVN?

> Oder schwebt dir noch
> eine ganz andere GUI vor?

Möglich.
Manchmal muß man etwas, was man nicht in Worte kleiden kann,
anders zusammen fassen, oder eine eigene Anwendung schreiben,
die es besser macht.

Geht zwar ein bischen in eine andere Richtung, aber wenn ich mir
unter OS-X den Finder zu Gemüte führe, der ist manchmal recht nervig.
Da ich das Teil oft benutze habe ich allmählich klar, was mich
dranb nervt, aber ich müsste auch einige Sätze nehmen um das zu
beschreiben.
Wikis habe ich noch zu wenige benutzt, weil die mich zu sehr genervt haben.
Wüde ich jeden Tag  mit schlechten Wikis arbeiten müssen, hätte ich nicht
nur klarer, woran es mangelt, sondern wahrscheinlich auch schon Alternativen
entwickelt. Aber das Geklicke war mir immer zu nervig.

Vielleicht müssten einfach bessere, an klassischer typografie angelehnte
Sachen mit in die Benutzung mit herein genommen werden.
Klarere Unterscheidung zwischen Lesen und Editieren, zwischen
verschiedenen Funktionsbereichen. Beispielsweise farblich oder so.

Was echt nervt, ist, daß man mit dem Browser editieren muß.
Das ist eigentlich das Hauptmanko.
Wenn mein $EDITOR statt dessen auf die Texte geöffnet werden würde,
dann wäre das sicherlich auch schon nicht mehr so ätzend.
Dann hätte man eine asubere Trennung von Eingabemodus und
Lesemodus und mehr Funktionalität als ein browser einem
für's Texte editieren anbietet.

Kann mir keiner erzählen, daß das eine Erleichterung ist, wenn
ich statt meines Lieblings-$EDITOR s im Browser herum tippen muß.
Deswegen muß dann da auch alles  ganz simpel sein, und reST scheint
mir da das sinnvollste.

Aber wenn der Browser mir automatisch meinen $EDITOR aufmacht,
dann wäre das eine schöne... sehr schöne Sache.

> 
> Ich denke da an GTK- oder ncurses-Applikationen, aber die würden
> ja letztlich doch wieder nur einen Texteditor nachbauen.

Der Texteditor ist dafür entwickelt worden, um Texte zu editieren.
Deswegen ist er (je nach Geschmack unterschiedelich, aber doch)
sehr spezifisch und leistungsfähig als Werkzeug zum editieren von Texten.

Wozu benutzt man Wikis?
Um Texte zu editieren - und zwar häufig.

Und wie geeignet ist dazu ein Programm, mit dem man im Normalfalle
verlinkte Texte LIEST?!

Ziemlich bescheiden ist so ein verlikte-Texte-Lese-Programm
dazu geeignet, häufige und viele Texte zu editieren.

 Wenn man einen Webbrowser als Editor vorgesetzt bekommt,
 dann ist das wie jemanden, der die Shell liebt, an ein
 System zu setzen, das einem keine anbietet. :->
 (Sollte in dieser Liste klar sein, was ich meine... ;-))

> Und Plugins
> für die bisherigen Texteditoren (vi,emacs,...) - außer SVN-Plugins -
> würden mir auch nicht groß einfallen.

Wie soll ich den Satz verstehen?

Also ein vi-Plugin fände ich serh gut. :)
Ich denke zumindest was das Editieren angeht wäre dann der gröbste
Ärger weg. :)

Aber aus typografischer Sicht ungünstig arrangierte
Ausgabefenster sind das zweite Hauptptoblem.
(Aber das trifft ja auch auf Applikationen zu, nicht nur auf Wikis.)

> 
> 
> Nun zur Sprache:
> 
> > > Solche Wiki-Sprachen gibt es auch. reStructuredText zum Beispiel hat
> > > eine Syntax, die den Plaintext-README-Dateien sehr ähnlich ist:
> > > 
> > > Überschrift
> > > -----------
> > > 
> > > Das /ist/ hervorgehoben.
> > > Hier eine Liste:
> > > * Element 1
> > > * Element 2
> > [...]
> > 
> > Aha, klingt schon mal gut.
> > Das ist dann wirklich simpel bedienbar und "intuitiv".
> 
> Naja ... für *dich* vielleicht. Jemand, der seine Erfahrungen nicht
> mit Textdateien, sondern nur mit Word, OpenOffice, etc. gemacht hat,
> und zuerst mit der Wikipedia ein Wiki kennengelernt hat, der wird
> lieber
> 
> 	= Überschrift =
> 
> statt
> 
> 	Überschrift
> 	-----------
> 
> schreiben.

OK, das ist ja auch noch erträglich,
wobei das zweite "=" schon zu viel Tipparbeit ist.
Auch die Unterstreichung könnte man dann weglassen,
wenn ein eingerücktes "=" bereits die Überschrift
kennzeichnet.
Also: wenig tippen, viel erreichen - das ist dann effizientes Arbeiten.
Wenn Wikis dieses ermöglichen sollen, warum dann die Unterstreichungen
oder die "=" am Ende?
Das ist überflüssiger, zeitklauender Krams.

> "Simpel" und "intuitiv" sind sehr subjektive Begriffe.
> Kennst du irgendwelche Maßstäbe, mit denen man sie objektiv
> bewerten kann?

Objektivität gibt es eh nicht.

(Aber das müssen wir jetzt nicht weiter ausführen...)

> 
> Ein Maßstab wäre z.B., dass die Textdatei als solche gut lesbar
> sein soll, also nicht wie ein Quellcode, sondern wie ein Dokument
> (z.B. ne Readme.txt) ... in dem Fall ist reStructuredText eindeutig
> das beste, und genau solch ein Format zu unterstützen, ist das
> explizite Ziel dieses Projektes.

Welches Projektes? Deines?

> 
> Geht es hingegen um einfachere Bearbeitung (im Sinne von Quellcode),
> so sind DokuWiki und MediaWiki geeigneter. Beispiel:
> 
> 	= Überschrift 2003 =

Warum nicht nur so:

  = Überschift 2003

Oder ggf. nur Einrückung.

Ist schon eine Weile her, daß ich mir mal das
Projekt Gutnberg angeschaut habe, aber die hatten
die Vorgabe: alles ASCII und keine speziellen Formatierungs-
Befehle (also auch kein LaTeX).

Man formatiert natürlich dennoch auf eine spezifische Weise,
und zwar Über Einrückungen und Leerzeilen.

Es wäre simpel, diese Formatierung dann mit einem
Konverter nach LaTeX zu wandeln und sich aus den
Unmengen von ASCII-Quellen dann (via LaTeX/TeX)
Unmengen von pdf's zu erzeugen. :)

Aller überflüssige Schnickschnack haben die weg gelassen,
und wer aus dem vorgegebenen Format sich ein eigenes
erzeugen will, kann es ja tun!

> 
> erfordert nur ein Hinztippen von " 2003". Hingegen:
> 
> 	Überschrift 2003
> 	----------------
> 
> erfordert neben der " 2003" noch ein "-----" darunter. Sowas kann
> auf Dauer nervig sein.

stimmt.

Aber das zweite "=" auch.
Und auch das erste.

Statt dessen zwei mal tab gedrückt (mit automatischer
Ersetzung in space oder so) und dann stehen die Sachen
auch da, wo sie hin sollen, wenn man nur via Einrückungen arbeitet.

Nur ein Beispiel, was mir gerade so ad hoc einfällt.

> 
> 
> Jenachdem, worauf man mehr Wert legt, sagen also selbst solche
> "objektiven" Kriterien nicht viel aus.

"Objectivity is the delusion that observations could be made without an observer."
                                                              (Heinz von Foerster)

Dann bracuht man eben eine einstellbare Syntax.
jaja, ich weiß, den Krams will sich kein Programmierer
unnötig aufhalsen!
Statt dessen plagt man lieber die Benutzer mit dem, was der
Programmierer sich im Rausch ausgedacht hat. ;-(

> 
> 
> > Das ist dann für die meisten Sachen sicherlich ideal.
> > Man kann dann seine Infos einfach im plain Text schreiben
> > und auch alte Text-Dokus html-isieren ("aufmotzen").
> 
> Das ist wahr.
> 
> Aber ich persönlich z.B. würde lieber in einer MediaWiki-artigen
> Sprache schreiben (weil ich das besser anpassen/bearbeiten kann),
> und dann *daraus* unter anderem *.txt-Dateien generieren.

Ist das dieses seltsame Klammer-Arien-Zeugs vom wiki.org?
Naja, nicht meine Welt.

Wann schreibst Du einen S-Expression Wiki? ;-)

> 
> Dafür als Tipp: HTML generieren, und dann mit "w3m -dump ..."
> in Text umwandeln. Ich habe damit schon gearbeitet, macht sich
> ganz gut.

Aha, noch ein Tool das ich nicht kenne... na, egal.
Wo nehme ich denn das html her, um text zu generieren,
den ich dann in den HTML-/Wiki rein stecke?
Ist das nicht doppelt-gemoppelter Blödsinn. oder habe ich gerade
nicht verstanden, wo Du bist/was Du mir sagen willst?

> 
> 
> Ich will nicht sagen, dass MediaWiki besser als reST ist, sondern
> nur, dass man das nicht pauschal entscheiden kann.
> 
> Oder fällt dir ein grundsätzlich anderes Konzept für das Verfassen
> von Dokumentationen ein? Dann wäre ich sehr interessiert.
> 

Wenn ich konkret vor dem Problem stünde, hätte ich vielleicht
neben den Ideen auch gleich was programmiert, aber oben habe
ich ja kurz schon was zu geschrieben: Überflüssige Sachen
raus lassen. Auch ein schliessendes "=" am Ende kann da schon zu nervig sein.
Wozu dieses denn da sein soll, ist mir unklar, kann man doch auch \n
als Ende-Marker nehmen.

> 
> Du redest immer von "zu kompliziert" oder "muss einfacher gehen"
> ... werd doch bitte mal konkreter.

s.o. (nur kleine ad-hoc Beipiele, erwarte keine langen Papers, ich gebe
meinen Eindruck als genervter, gelegentlicher Anwender wieder)

> Was würdest du anders machen,

s.o.

> und vorallem: Wie?

Wie, wie?  ;-)

> Falls du da besonders neue kreative Ideen hast,
> wäre ich sehr interessiert. Aber bisher lief alles auf Sachen hinaus,
> die es längst gibt.

Sachen die es gibt zu nehmen kann sehr kreativ sein, wenn vorher
niemand auf die Idee gekommen ist. :)

Nen vi statt eines Texteingabefensters eines Browsers ist
IMHO eine kreative Idee, weil sie etwas neues einführt, auch
wenn es eigentlich nichts neues ist.

Aber bisher habe ich es noch nie erlebt, daß ich via Webbrowser
meinen Editor benutzen kann, um Texte zu tippen.
( Vermutlich, weil ich vi und nicht emacs nehme, werden mir
  die Emacs-Leute jetzt vielleicht zurufen? ;-))

> Deshalb verstehe ich nicht ganz, wieso du den
> Status Quo so verteufelst.

Ist es ein bischen klarer geworden?

Es soll ja Leute geben, die ganze Perl-Applikationen
im Webbrowser entwickeln.
Ich finde sowas immer nervig.

Aber leider erwarten die Leute ja sowas.
Na gut, die Kunden kriegen es - aber man selber darf bitte
wieder den Lieblings-$EDITOR benutzen, ja?

[...]
> > > Sie haben sich also erst
> > > gar nicht an eine Weboberfläche festgedongelt. Wäre SubWiki so
> > > flexibel, dass es z.B. reST versteht, dann 
> > 
> > SubWiki ist etwas, das Du empfiehlst?
> > Aber man müsste noch reST "einbauen"?
> 
> Eben, genau das habe ich gerade gesagt. :-)
> SubWiki ist ein guter Ansatz. MediaWiki übrigens auch. Und auch
> DokuWiki. Alle haben wunderbare Ideen und bieten coole Vorteile.
> Aber solange man diese nicht kombinieren kann, ist man an die
> Nachteile jedes einzelnen dieser Wikis gebunden.

Was soll man dann Deiner Meinung nach machen?
Alles zusammen koppeln, oder was neues entwickeln?

Gibt es denn eigentlich eine gute Übersichtsseite, die mal alle
Eigenschaften (Vor-/Nachteile) _klar_ gegenüberstellen?

[...]
> > Also: entweder ich programmiere etwas selber.
> > Dann weiß ich, was da passiert und dann baue ich es nach meinem
> > Gusto (oder wenn es bezahlt ist nach dem Gusto des Auftraggebers).
> > 
> > Oder ich programmier nicht etwas selber, dann schaue ich mir an, ob das
> > brauchbar ist, und wenn nicht, vergesse ich den Kram gleich wieder.
> 
> Es gibt aber in sehr vielen "unbrauchbaren" Projekten auch einen guten
> "Kern", d.h. wenigstens eine wirklich gute, innovative Idee. Und eben
> solche Ideen muss man zusammentragen. Nicht einfach nur: Software-A
> genügt gerade so meinen Ansprüchen, deshalb nehme ich es. Software-B
> genügt ihnen nicht, also ignoriere ich es. So kommt man doch nicht
> weiter. Wenn Software-B eine gute Idee enthält, die eine radikale
> Verbesserung ermöglicht, würde ich z.B. lieber Software-B unterstützen,
> als weiter mit Software-A rumzudümpeln.

Wenn ich meine Sachen dann aber ohne lange Vergleichsstudien
schneller in plain Text erledigt habe oder in lout/LaTeX
(also Tools, die ich bereits kenne),
dann studiere ich nicht noch extra zwanzig verschiedene
Wiki-Programme.
Wenn Du ohnehin schon mit zig Wikis vertraut bist,
ist auch klar, daß Du die alle kennst. (Das macht die
aber auch nicht besser ;-))

> 
> > Ist es brauchbar, dann wäge ich also noch ab, ob der Installationsaufwand
> > sich lohnt, das Teil zu installieren (Vorteile vs. Aufwand).
> 
> Ja, aber das musst du auch gegen deinen eigenen Programmier-Aufwandt
> abwägen. Auch die Möglichkeit, das bestehende Projekt zu verbessern,
> sollte immer in Betracht gezogen werden.

Am Browser Texte zu editieren, weil das Wiki-programm der neueste Schrei
(ääähh, ich meinte Hype) ist, statt meinen Editor zu nehmen, mit selbigem
ich schneller ans Ziel komme (:set ai), das halte ich nicht für geeignet.

Aber vielleicht ist ja auch nur mein Browser nicht gut genug... ;-)

> 
> Da hast du schon ein paar mehr Sachen, die du gegeneinander abwägen musst.
> 

Eben!

[...]
> > Kommt da nun jemand daher, der selber an Wiki-SW entwickelt oder dies
> > vor hat, dann muß er/sie/es sich schon um die Marktanalyse (um mal ein
> > ketzerisches Wort zu benutzen) selber kümmern.
> > Meine bekundungen über miese Software sind rein aus der Benutzerperspektive
> > und eine Software die nicht DAU-tauglich ist, ist aus benutzerperspektive
> > Mist.
> 
> Full Ack. Wiegesagt: Wikis ist (auch rein vom Konzept her) in dieser
> Richtung IMHO das beste, was wir haben. Mir scheint aber, du willst
> nicht bessere Wikis, sondern noch völlig andere Konzepte.

Von mir aus nenn es auch andere Konzepte.
Ob es andere Wikis oder andere Konzepte sind, auch das ist eine
Frage, wwie man seine Begrifflichkeit da einsetzt, welchen
Blickwinkel man hat.

> Dann jedoch
> verlierst du dich in Anspielungen und schwammigen Formulierungen.

Jetzt hör doch mal auf zu nerven!

Darf ich Dich daran erinnern, wie schwammig Du wurdest, als Du Deine
super-hyper-HYPEigen neuen Softwarekonzepte vorgestellt hast?
Was war nach langem nachbohren das Ergebnis?
"Naja, ich implementiere das erst mal und dann kann ich es auch besser erklären."

Also dann muß ich jetzt leider auch diese Antwort geben: Ich kann es nur so erklären,
wie in den bisherigen und dieser Mail geschehen.
Der Rest wäre dann: Wenn ich es besser gemacht habe, kann ich es auch erklären.

Genauso war es übrigens auch bei pftdbns. Da habe ich auch vorher
nicht gewußt, wie ich es audrücken soll. Mit der Implementierung kam
dann auch die Klarheit => Programme als ausführbare Prosa über
ein (in diesem Falle) technisches Thema.

So, mit diesen Sätzen habe ich fertig. ;-)

Ciao,
  Oliver

P.S.: Na gut, einen lege ich noch nach. ;-)

> Auf der einen Seite das lokale Arbeitsverzeichnis, an dem man größere
> Überarbeitungen mit den Tools seiner Wahl (z.B. Emacs, vi, ...)
> vornehmen kann, mit den Subversion-Tools seiner Wahl (Kommandozeile,
> GUI, ..). Also genau das, was sich auch in der SW-Entwicklung bewährt
> hat.
> 
> Auf der anderen Seite ein Webinterface, durch das man "mal eben schnell"
> ein paar Änderungen vornehmen kann. Jederzeit, auch im Internetcafé, mit
> einem beliebigen Browser. Auch für Anfänger gut geeignet, die bereits
> Wikis und/oder Webforen kennen.

Hmhhh, das erinnert mich jetzt gerade an opentheory.org: Sowohl
Web- als auch Mailinterface... (statt entweder-oder).

P.P.S.: OK, dochnoch weiter. ;-)

> 
> 
> Wenn du eine grundsätzlich andere, einfachere, benutzerfreundlichere,
> was-weiß-ich-Idee oder -Lösung hast, nur her damit. Würde mich sehr
> interessieren. Gerade, um darüber mal Meinungen zu hören, habe ich
> meine eigene Meinung hier so ausführlich dargelegt.

In den letzten Tagen geht mir wieder Literate Programming durch den Kopf....

[...]
> Analog dann die Berlinux-Suche:
> 
> > docfind -ititle=".*"berlinux.*|.*vorbereitung.*" \
> >          -searchcategories=web,ftp -doctype=html,pdf \
> >          -reportformat=text
> 
> Was hältst du von obigem Ansatz? Dann wäre dein docfind
> quasi ein
> 	alias docfind='httptool http://www.belinux.de/search'
> oder so ähnlich.

Kenne httptool nicht, denke aber (Deinem bischen Code entnehmend)
lautet die Antwort "nein".
Aber da müsstest Du noch etas mher zu httptool sagen.
Google bringt mir nur Müll.

> 
> 
> >> > Kennst du eine?
> > 
> > Es gibt viele Einzelteile, die ein bischen was können,
> > aber noch nix wirklich Knaller-mäßiges, was die Sachen
> > zusammen anbietet.
> 
> Eben. Also benennen wir doch einfach mal die Einzelteile, und schauen
> uns ihre Vor- und Nachteile an, und schauen, wie man sie (rein vom
> Konzept her) zusammenbringen kann. Um genau solche Ideen
> zusammenzutragen, schreibe ich doch hier!

ach so. :)

> 
> > ...obwohl es ja einen Browsr gibt, der ja sgrep-like
> > arbeitet (habe ich aber noch nicht ausprobiert).
> 
> Vielleicht kann das w3m.  :-)

Es klingt so, als ob Du sgrep nicht kennst.
Oder ich finde in  http://w3m.sourceforge.net/MANUAL
nicht, was der Tausendsasser w3m noch so alles kann
(undocumented features? ;-))

Ne, schau mal nach "LAPIS" (leider in meiner garnicht-Freude
Programmiersprache implementiert...) die Features fehlen
im vi noch. ;-)

Aber man sgrep wäre auch mal nett. ;-)

Stichwörter: Multi-Region editing, outlier-findings, region algebra,
pattern by example, ... ach ja, nicht zu vergesse: browser shell :)

Wenn sowas serverseitig angeboten werden würde (Hallo Google, bitte
implementieren! :)) dann wäre das 'n Knaller. :)

BTW: Schaue mir LAPIS auch eben das erste mal praktisch an,
     wollte ich schon seit zwei Jahren oder so habe nun endlich
     die Musse dazu...
     ...aber mit den Multiple-selects und dem Ctrl klappt nicht...
     .... naja, Java halt. :(  Oder ist das auf'm Mac anders codiert?

Die Region-Algebra und LAPIS/sgrep sind mir begegnet, nachdem ich über
längere Zeit eine geeignete Sprache suchte, die mir wenig strukturierte Daten
gut analysieren kann.
Hatte schon was eigenes entwickeln wollen, da bin ich bei einer
Recherche zu einem ganz anderen Thema dort gelandet... und war very happy. :)

Ich hatte hier vor langer Zeit mal gefragt, ob es
eine Sprache oder einen Editor gibt, der z.B. folgendes kann:

 $  in each paragraph which contains " hello" do s/Guten Tag/Guten Abend/g

(nur sinngemäß nehmen, es schwebte mir eine etwas andere Syntax vor,
 habe ich aber vergessen, wie es genau werden sollte.

Aber im Prinzip so.

Naja, geht prinzipiell mit RA. :)

(Das war übrigens auch eine Sache, die ich letztens zu Dir in ner PM
 mal erwähnte als, daß ich mich da mit einem Thema beschäftige, das ich
 wieder aufgegriffen hatte -> RTrees für RA.)

> 
> > Bei Heise hatte ich mal nachgefragt, ob die einem nicht
> > eine echte oder virtuelle SQL-Anbindung an die Job-Datenbank
> > ermöglichen... oder eine Volltextsuche ...
> > wollten die aber nicht machen. (Ist aber schon länger her.)
> 
> Könnte auch Datenschutzgründe haben.
> Außerdem ist das ein riesen Aufwandt ist, sowas sauber abzutrennen.

Naja, igentlich muß man da nur etwas aufpassen, wer was lesen darf...
Sensible Daten sollten eh separat von Webdaten laufen, und ob man
nun alles erklickt oder per direkten Zugriff erfährt...
...wenn es eh aus der selben DB kommt, bloß einmal noch durch's
HTML-Nadelöhr muß...

> 
> Auf Wunsch eines einzelnen Herren würde ich sowas auch nicht
> gleich integrieren.  ;-)

Naja, das könnte man ja als Feature für alle anbieten.
Aber da sind's dann doch zu wenig Daten, die da im Jobforum liegen... :->

[SOAP]
> Das gute alte CGI-Interface ist mir irgendwie sympatischer. :-)
> Parameter via POST und GET, dann kann man zur Not sogar ein
> HTML-Formular drumherum packen, wenn man will. Jeder kann
> es via Kommandozeile abrufen (wget 'http://.../xxx?param1=val1&...'),
> und wenn die Rückgabe unbedingt strukturiert sein muss, dann
> entweder entsprechend formatierter Plaintext oder XML. Ini-Syle
> hätte auch was :-)

ja, ich weiß, gleich kommst Du wieder mit S-Expressions! ;-)

> 
> Keinen Plaintext anzubieten, sondern "nur" Webseiten mit HTML-Content,
> der auch in w3m & lynx gut aussieht, halte ich übrigens für einen
> guten Kompromiss zwischen Aufwandt und Nutzen. Ich habe kein Problem
> damit, dass ein Großteil der Informationen "auf Webseiten im HTML-
> Format versauert", hauptsache, man kommt mit w3m und lynx daran.

ach soooo einer bist Du ;-)

hehehh... stimmt, lynx müsste ich mir hier auch mal
drauf knallen. Aber w3m ist auch ein Textbrowser, wie ich gerade
ergooglet habe...
...aha, viell. auch mal antesten.

[...]
> > Man könnte sonst auch eine pseudo-shell anbieten,
> > wo man statt dem typischen geklicke eine virtuelle
> > Shell anbietet, wo ich - mausfrei :) - ne Suche
> > abgeben kann - am besten mit Tools, die grep/glimpse etc.
> > noch übertreffen.
> 
> Ja, aber wieso nicht die bisherigen Interfaces gleich
> direkt ansprechen? Deine Kritik bezog sich ja AFACIS nur
> auf die Client-Seite. Serverseitig kann das ja ruhig ein
> ganz normaler HTTP-Dienst sein.

Aber bitte mit mehr Features!
Wenn ich bei Google (oder auch lokal auf einer installierten
Suchmaschine) eine Suche mache nach Keywords und bekomme
nur Dokumente, die die Keywords enthalten, aber nicht
auch ob diese z.B. in einem bestimmten Pattern enthalten
sind (sgrep-like, also RA-like), dann ist das Suchergebnis
eben nicht so besonders aussagekräftig.
Wenn ich dann erst alle Doks anschauen muß und nach dem Download
entsheide, ob es passt, ist das auch aufwändig.

Wenn google da ein Pattern schon prüft, und damit noch bessere
Suchergebnisse heraus geben kann, dann wäre das doch was *WIRKLICH*
feines! :)

> Nur auf Clientseite müssen
> entsprechende Tools her.

Nein, die Suche soll verbnessert werden, Daß das auch mit http
als Übermittlung gehen kann ist damit ja nicht ausgeschlossen.

> Wiegesagt, vielleicht gibt's die
> sogar schon.

LAPIS anschauen.

Dann dieses Konzept serverseitig auf Suchmaschine aufsetzen.
DAS ist ein Bringer! :)

Selbstverständlich dann auf Clientseite eben auch solche
Features haben (also guten Browser/Editor).

> 
> > Nimm obiges Beispiel eines "docfind"-Tools.
> > 
> > Auch das: nur ein beispiel, wie es sein könnte.
> > Wenn man da sgrep-Features mit einbauen könnte,
> > und auch kaskadieren könnte bei der Suche,
> > das wäre superfein.
> 
> Das wäre dann ein serverseitiges Problem.

Ja.

> Aber ich denke, mein
> Ansatz würde deinem Wunsch nach mehr Einfachheit auf Clientseite
> schon voll erfüllen. Was hältst du davon?

Sehr viel Optimierung sehe ich da nicht.
Oder habe ich da irgendwas wichiges übersehen?
Ist es mehr als nur ein "naja, baue ich mir halt ein Script
um die Sacxhen, die der Server nicht anbietet, lokal zu emulieren"?!
=> Netz dicht machen?!

> 
> > (Wobei so Kaskadierungen zum Beipiel mit einer GUI
> >  gut handhabbar sind - da macht IMHO sogar ne GUI
> >  Sinn, und daß die bisherigen GUIs solche features
> >  nicht anbieten, zeigt, daß die Leute nicht wirklich
> >  gute Ideen haben, wenn sie was programmieren...
> 
> w3m?  :-)

Ich noch nicht kenn....

> 
> Dann bräuchte man die kaskadierte Suche nur noch Serverseitig
> entwickeln, und bräuchte kein extra Protokoll etc. dafür, und
> wer die Commandline nicht mag, kann auf dem selben Wege auch
> via Firefox daran.

Gegen http habe ich mich garnicht ausgesprochen.

[...]
> Die Ideen und die Ausdrucksfähigkeit von jedemanden zu kritisieren,
> ist übrigens IMHO genau das gleiche, wie seine Software zu kritisieren.
> (weil dort sehr ähnliche Fähigkeiten gefordert sind ... nur das einmal
> in einer Maschinensprache, das andere Mal in einer menschlichen)

Du stellst Menschen und Maschinen auf die selbe Stufe.
Katastrophal!

[...]
> > Aber gut, greife ich das doch nochmal auf.
> > Vielleicht macht es ja doch Sinn, darzustellen, was genau ich meine.
> 
> Natürlich macht es Sinn. Schon allein deshalb, weil es sonst all dein
> bisher geschriebenes umsonst wäre, weil's kaum einer verstanden hat
> und du somit kein Feedback erhältst. Es ist immer ratsam, so zu
> schreiben, dass man verstanden wird, sonst kann man es auch gleich
> sein lassen.  ;-)

Jaja, so wie Du mit Deinen seltsamen SW-Konzepten, die so super sind,
aber auch nicht erklärbar. ;-)

Ciao,
   Oliver