was ich noch toll finden würde
Klaudia Schröder
- zu diesem forum
0 Stefan0 Lulu
0 Michael Schröpl0 Kess0 Klaudia Schröder
Hallo !
Des öfteren hab ich beobachtet, wie einzelne ein Posting merhfach losschicken,
da sie annehmen, dass keiner mehr so weit scrollt um die alten Einträge zu
lesen. Oder es bleibt eine Antwort aus und weiss nicht woran liegt. (woher auch?)
Wenn's möglich wäre, die Aufrufe eines Postings zu speichern (ich weiss, wieder viel Programmieraufwand)
und diese anzuzeigen, hätte man doch einiges gewonnen, oder?
Ich fänd's sehr interessant, wenn ein Posting 100 mal gelesen wurde, obwohl keine Antwort oder
bisher gar nicht gelesen.
Ich kann mir dann einen viel besseren Überblick machen, ob die Frage auch für andere "zu schwer" ist,
oder was auch immer.
Da das Forum doch jetzt über ne Datenbank läuft (oder nicht?), ist es ja nicht mehr ganz so viel Aufwand, oder nicht?
Was haltet Ihr davon?
Gruß,
Klaudia (mit 'K' ! und nicht irgendwie verwandt mit dem Gerhard)
Hi,
meiner meinung keine schlechte idee, aber das duerfte noch ein bisschen dauern, da erstmal das archiv eingerichtet... werden muss
mfg
stefan
Hi folx
was ich noch super und nützlich finden würde, ich habe
das auch schon in einigen Foren gesehen, wäre die
Möglichkeit einzelne Threads zu abonnieren.
D.h. man erhält bei jedem neuen Posting eine Nachricht per
E-Mail.
Viele Grüße
Lulu
Hi,
das war auch schon mal in der diskussion, schon bevor das forum geschlossen wurde.
das ist damals nicht gemacht worden. hauptsache wegen den gigantischen traffic...
es gab warscheinlich aber noch andere gruende, die mir aber leider nicht bekannt sind, bzw. mir grad nicht einfallen*g*
mfg
stefan
Hi Leute,
ich fände es auch recht interessant einen User-Zähler zu sehen.
Der Aufwand ist nicht so hoch und man wüsste, wieviele Leute sich gerade im Forum bewegen. Wäre doch chic, oder?
Bye
Craig
hi!
ich fände es auch recht interessant einen User-Zähler zu sehen.
Der Aufwand ist nicht so hoch und man wüsste, wieviele Leute sich
gerade im Forum bewegen. Wäre doch chic, oder?
Schön, dass ihr alle schnell zu implementierende Vorschläge macht...
Unter http://sf.net/projects/selfforum/ ist ja auch der Source und
ein Patch-Tracker verfügbar. Ihr ladet euch also schnell den Source
runter, schreibt einen Patch und schickt den ein. Dann können wir
schnell darüber entscheiden, ob wir diese Features aufnehmen.
bye, Frank!
ps. http://www.teamone.de/selfaktuell/forum/faq/forumsfaq_1.htm#a5
Hi auch,
ich fände es auch recht interessant einen User-Zähler zu sehen.
Der Aufwand ist nicht so hoch und man wüsste, wieviele Leute sich
gerade im Forum bewegen. Wäre doch chic, oder?
HTTP ist ein zustandsloses Protokoll mit grundsätzlich zusammenhangs-
losen Einzelabfragen - kein Session-Protokoll mit keep-alive-Signalen etc.
Wer will wie feststellen, daß Du Dich noch im Forum "aufhältst"?
Viele Grüße
Michael
Hi Michael,
Wer will wie feststellen, daß Du Dich noch im Forum "aufhältst"?
Die Java Servlet API?
Grüße,
Martin
Moin,
Wer will wie feststellen, daß Du Dich noch im Forum "aufhältst"?
Die Java Servlet API?
wieso, transformiert die API HTTP in ein Session-Protokoll?
Wo kann ich mehr darueber erfahren? ;-) (RFC????)
Viele Gruesse,
n.d.p.
Hi,
wieso, transformiert die API HTTP in ein Session-Protokoll?
Wo kann ich mehr darueber erfahren? ;-) (RFC????)
Ja, via Session-Tracking (Cookie-based oder, das wird von der Engine automatisch ermittelt, URLEncoding).
Mit RFCs kann ich Dir nicht dienen, aber schaue mal in http://java.sun.com/products/servlet/2.2/javadoc/index.html unter Interface HttpSession.
Tomcat ist eine Referenz-Implementierung der Api -> http://java.sun.com/products/servlet/download.html#specs
Auch viele Grüße,
Martin
Moin,
wieso, transformiert die API HTTP in ein Session-Protokoll?
Wo kann ich mehr darueber erfahren? ;-) (RFC????)
Ja, via Session-Tracking (Cookie-based oder, das wird von der Engine automatisch ermittelt, URLEncoding).
[...]
erstmal haben diese Sessions nichts mit HTTP zu tun, sondern sie benutzen HTTP in einer tieferen Schicht (HTTP ist eben das, was Browser im allgemeinen koennen (sollten ;-)).
ansonsten sehe ich dabei hauptsaechlich zwei Probleme:
1.) hier wird nichts getrackt (spaeter ist eine optionale Userregistrierung geplant, aber auch da wird wahrscheinlich nichts getrackt werden)
2.) das Problem ist ja eher allgemein: das alles aendert nichts an der Zustandslosigkeit von HTTP - es gibt den Zustand "Online" nicht (es gibt ihn schon, so fuer etwa die Ladezeit der Seite, ist aber nicht ausreichend, um extrapolative Aussagen ueber die Zeit zu machen, die User mit dem Betrachten des Dokuments zubringt). Genausogut kann ich per Zufallsgenerator da eine Zahl hinschreiben.
Viele Gruesse,
n.d.p.
Moin,
Moin (Ihr Nordländer habt schon eigenartige Begrüßungen..;)) )
Diese Arte der Antwort habe ich befürchtet bzw. erwartet ;-))
wieso, transformiert die API HTTP in ein Session-Protokoll?
erstmal haben diese Sessions nichts mit HTTP zu tun, sondern sie benutzen HTTP in einer tieferen Schicht (HTTP ist eben das, was Browser im allgemeinen koennen (sollten ;-)).
Ist mir klar.
ansonsten sehe ich dabei hauptsaechlich zwei Probleme:
1.) hier wird nichts getrackt (spaeter ist eine optionale Userregistrierung geplant, aber auch da wird wahrscheinlich nichts getrackt werden)
ist "hier" == SELFForum?
2.) das Problem ist ja eher allgemein: das alles aendert nichts an der Zustandslosigkeit von HTTP - es gibt den Zustand "Online" nicht (es gibt ihn schon, so fuer etwa die Ladezeit der Seite, ist aber nicht ausreichend, um extrapolative Aussagen ueber die Zeit zu machen, die User mit dem Betrachten des Dokuments zubringt).
Mir ist schon bewusst, dass keine API dieser Welt (Universum will ich nicht sagen..) das per Definition zustandslose HTTP-Protokoll
in ein zustands"volles" transformieren kann.
Was genau meintest Du dann mit Deiner Frage nach einer "Transformation von HTTP in ein Session-Protokoll"?
Genausogut kann ich per Zufallsgenerator da eine Zahl hinschreiben.
Nichts anderes macht die API beim URLEncoden..
Noch mehr Grüße,
Martin
Hi,
1.) hier wird nichts getrackt (spaeter ist eine optionale
Userregistrierung geplant, aber auch da wird wahrscheinlich
nichts getrackt werden)
ist "hier" == SELFForum?
Momentan noch (solange das die einzige Installation ist).
Aber das SelfForum soll sich bezüglich Quelltext in nichts von dem
unterscheiden, was bei SourceForge allgemein verfügbar ist, d. h. von
SELF gewünschte Features werden üblicherweise Konfigurations-Parameter
zum Ein- bzw. Ausschalten derselben bewirken. (Das geht in den ebenfalls
in XML realisierten Konfigurationsdateien sehr elegant.)
Was genau meintest Du dann mit Deiner Frage nach einer "Transformation
von HTTP in ein Session-Protokoll"?
Nun, Du könntest auf dem Server beim Login / Erstzugriff eine eindeutige
Session-ID vergeben und an den Client übertragen (Cookie, CGI-URL, ...).
Jeder Request mit dieser ID würde ein keepalive-Signal zum Server senden
Parallel dazu läuft auf dem Server ein daemon, der periodisch alle
SessionID-Dateien löscht, die älter sind als ein definiertes Zeitintervall
Du wüßtest also nicht, wer wirklich online ist, aber Du wüßtest, wer sich
bisher an die Spielregeln gehalten hat ... und deshalb *wahrscheinlich*
noch online ist. Und alles liefe über HTTP.
Viele Grüße
Michael
Hi Michael,
Momentan noch (solange das die einzige Installation ist).
Aber das SelfForum soll sich bezüglich Quelltext in nichts von dem
unterscheiden, was bei SourceForge allgemein verfügbar ist, d. h. von
SELF gewünschte Features werden üblicherweise Konfigurations-Parameter
zum Ein- bzw. Ausschalten derselben bewirken. (Das geht in den ebenfalls
in XML realisierten Konfigurationsdateien sehr elegant.)
Ich weiß. Das lerne ich auch gerade ;-))
Nun, Du könntest auf dem Server beim Login / Erstzugriff eine eindeutige
Session-ID vergeben und an den Client übertragen (Cookie, CGI-URL, ...).
Jeder Request mit dieser ID würde ein keepalive-Signal zum Server senden
- stell Dir vor, Du hast dort in /tmp eine Datei mit dem Namen dieser
Session-ID und machst bei jedem CGI-Aufruf ein "touch" darauf, als eine
ganz einfache Art der Implementierung.
Parallel dazu läuft auf dem Server ein daemon, der periodisch alle
SessionID-Dateien löscht, die älter sind als ein definiertes Zeitintervall
- das wäre das "automatische logout".
Ein nachfolgender Request mit dieser ID würde dann (z. B. per URL-
Redirection) ein neues Login erzwingen.
Du wüßtest also nicht, wer wirklich online ist, aber Du wüßtest, wer sich
bisher an die Spielregeln gehalten hat ... und deshalb *wahrscheinlich*
noch online ist. Und alles liefe über HTTP.
OK, jetzt bin ich total verwirrt.
Das, was Du mir erklärtest, ist doch Session-Tracking, Cookie-basiert oder eben über encodierte URLs, welche dann zusätzlich eine SessionID enthalten. Und nichts anderes macht die Servlet-API (mit dem Unterschied, dass das Handling komplett im Speicher erfolgt). Ich setze einen Timeout-Wert in der server.xml von Tomcat, alle registrierten Sessions werden nach Überschreitung dieses Zeitwertes seit dem letzten Request gelöscht bzw. invalidiert. Erfolgt erst danach ein Neuzugriff, muss ein ReLogin erfolgen.
Aber genau das, so verstand ich zumindest n.d.p., war nicht die erwartete Antwort auf seine Frage.
Was mich aber noch interessiert: Wie soll ich das mit dem keepalive-Signal verstehen? Meinst Du damit den HTTP-Header Parameter? Und, ist der Zweck Performanceoptimierung, also der Hinweis an den Server, nur bei Empfang eines solchen Signals üperhaupt in /tmp nach einer entsprechenden Cookie-Datei zu suchen?
Viele Grüße,
Martin
Hi auch,
Das, was Du mir erklärtest, ist doch Session-Tracking, Cookie-basiert
oder eben über encodierte URLs, welche dann zusätzlich eine SessionID
enthalten. Und nichts anderes macht die Servlet-API (mit dem Unterschied,
dass das Handling komplett im Speicher erfolgt).
Aber genau das, so verstand ich zumindest n.d.p., war nicht die
erwartete Antwort auf seine Frage.
Ich kenne Tomcat nicht. Ich wollte nur skizzieren, wie man Session-Tracking
mit HTTP annähern kann - und was dabei immer noch nicht so toll ist.
Im Prinzip bräuchte man periodische Zugriffe des Clients auf den Server
unabhängig von Benutzer-Interaktionen, was aber gerade *nicht* der Sinn von
HTTP ist, welches den erzeugten Traffic gemäß der gestellen Anforderungen zu
minimieren versucht (und dafür ja sogar cacheing einsetzt).
Wie soll ich das mit dem keepalive-Signal verstehen?
Als Trigger, ein weiteres "touch" auf die Session-Datei zu machen, damit sich
ihre Lebensdauer entsprechend verlängert.
Und, ist der Zweck Performanceoptimierung, also der Hinweis an den
Server, nur bei Empfang eines solchen Signals üperhaupt in /tmp nach
einer entsprechenden Cookie-Datei zu suchen?
*Jeder* einzelne HTTP-Aufruf löst eine Kombination aus Prüfung der Session-
Datei (ggf. mit Prüfung des time stamp - auch dies kann implizit zu ihrer
Löschung und zum ReLogin führen!) und anschließendem "touch" aus (falls
die Lebensdauer der Session so definiert ist - es kann natürlich auch die
Gesamtdauer limitiert sein oder was auch immer).
"Suchen" beschreibt den Zugriff insofern etwas merkwürdig, da ja der Pfadname
aufgrund der Session-ID exakt bekannt ist, also ein direkter Zugriff genügt.
Viele Grüße
Michael
Hi auch,
Ja doch,
Ich kenne Tomcat nicht. Ich wollte nur skizzieren, wie man Session-Tracking
mit HTTP annähern kann - und was dabei immer noch nicht so toll ist.
OK, dann war ich also doch nicht verwirrt ;-)
Im Prinzip bräuchte man periodische Zugriffe des Clients auf den Server
unabhängig von Benutzer-Interaktionen, was aber gerade *nicht* der Sinn von
HTTP ist, welches den erzeugten Traffic gemäß der gestellen Anforderungen zu
minimieren versucht (und dafür ja sogar cacheing einsetzt).
Klar - nicht umsonst werden im Mobilfunkbereich die verbindungsorientierten Protokolle langsam auf paketorientierte (und damit auch nicht-verbindungsorientierte )umgestellt.
Anyway, schönes WE wünsche ich..
Grüße,
Martin
Hi auch,
es gab warscheinlich aber noch andere gruende, die mir aber leider
nicht bekannt sind, bzw. mir grad nicht einfallen*g*
schon mal </cgi-local/self/such.pl> probiert?
Viele Grüße
Michael
Hi,
Des öfteren hab ich beobachtet, wie einzelne ein Posting mehrfach
losschicken, da sie annehmen, dass keiner mehr so weit scrollt um
die alten Einträge zu lesen.
Oder es bleibt eine Antwort aus und weiss nicht woran liegt.
(woher auch?)
FAQ lesen hilft. (</selfaktuell/forum/faq/forumsfaq_2.htm#a3>)
Bewußte Verstöße gegen die FAQ erhöhen weder den Sympathiewert des
Fragenden noch die Motivation der Leser, seine Fragen zu beantworten.
Wenn's möglich wäre, die Aufrufe eines Postings zu speichern (ich
weiss, wieder viel Programmieraufwand) und diese anzuzeigen, hätte
man doch einiges gewonnen, oder?
Meinst Du mit "Aufrufen" die Zahl der Lesevorgänge? (page views?)
Die wird gespeichert (weil sie Bestandteil des Voting-Verfahrens ist).
(</selfaktuell/forum/faq/forumsfaq_1.htm#a7>)
Ich fänd's sehr interessant, wenn ein Posting 100 mal gelesen wurde,
obwohl keine Antwort oder bisher gar nicht gelesen.
Diese Information anzuzeigen ist eine "politische" Frage, keine
technische. (</selfaktuell/forum/faq/forumsfaq_1.htm#a7>)
Ich kann mir dann einen viel besseren Überblick machen, ob die Frage
auch für andere "zu schwer" ist, oder was auch immer.
Wie kannst Du aus dem Fehlen einer Antwort auf dessen Ursache schließen?
Da das Forum doch jetzt über ne Datenbank läuft (oder nicht?),
Nein - über XML-Dateien. (</selfaktuell/forum/faq/forumsfaq_1.htm#a4>)
Aber das bietet recht ähnliche Möglichkeiten.
ist es ja nicht mehr ganz so viel Aufwand, oder nicht?
Siehe oben (gar keiner).
Viele Grüße
Michael
Hallo Michael,
ist es ja nicht mehr ganz so viel Aufwand, oder nicht?
Siehe oben (gar keiner).
naja, das stimmt so hundertprozentig nicht. Zwischen Speicherung eines Wertes und dessen Anzeige an einer bestimmten Stelle besteht schon ein Unterschied. Die Views werden nicht in der Forumshauptdatei vorgehalten.
Viele Grüße
Kess
Hallo Kess,
ist es ja nicht mehr ganz so viel Aufwand, oder nicht?
Siehe oben (gar keiner).
naja, das stimmt so hundertprozentig nicht. Zwischen Speicherung
eines Wertes und dessen Anzeige an einer bestimmten Stelle besteht
schon ein Unterschied. Die Views werden nicht in der Forumshauptdatei
vorgehalten.
soweit ich Klaudia verstanden habe, hat sie nicht gefordert, daß der
view-count in der Hauptdatei angezeigt wird - und wenn eine Anzeige
innerhalb eines Postings reicht, dann ist der Aufwand ungefähr eine
Zeile mit einem print()-Statement.
Viele Grüße
Michael
soweit ich Klaudia verstanden habe, hat sie nicht gefordert, daß der
view-count in der Hauptdatei angezeigt wird
hmmm, stimmt. Wo du es sagst. Sie will ihr eigenes Posting anhand der Views und der eingegangenen oder nicht eingegangenen Antworten bewerten.
- und wenn eine Anzeige
innerhalb eines Postings reicht, dann ist der Aufwand ungefähr eine
Zeile mit einem print()-Statement.
Das müßte demnach wirklich dafür ausreichen.
Etwas mehr als ein print wäre es schon, wenn das Feature optional sein soll. Sehr viel mehr allerdings nicht. Nicht bei diesem Forum mit seinem modularen Konzept. Den Entwicklern sei Dank.
Viele Grüße
Kess
Hallo Kess,
- und wenn eine Anzeige
innerhalb eines Postings reicht, dann ist der Aufwand ungefähr eine
Zeile mit einem print()-Statement.
Das müßte demnach wirklich dafür ausreichen.
Etwas mehr als ein print wäre es schon, wenn das Feature optional
sein soll. Sehr viel mehr allerdings nicht. Nicht bei diesem Forum
mit seinem modularen Konzept. Den Entwicklern sei Dank.
Fein, daß wir das gleich sehen.
Und wo wir jetzt wissen, was eigentlich gewünscht ist:
https://sourceforge.net/tracker/?func=add&group_id=21057&atid=371057
denn bis hierher machte die Diskussion an der aktuellen Stelle Sinn,
und dort geht sie sinnvollerweise weiter.
Viele Grüße
Michael
(der sich damit gewissermaßen als Ideen-Filter betätigt)
Und wo wir jetzt wissen, was eigentlich gewünscht ist:
öhm... <spitzfindig> wo steht, daß dieses Feature hier gewünscht ist? Ich schrieb nur, daß es tatsächlich nicht aufwendig sein dürfte.</spitzfindig> ;-))
Übrigens: nicht jede Idee muß auch umgesetzt werden. Wenn ich mir die Ideenproduktion hier ansehe, dann wird mir Angst um Bange um die wirklich wichtigen Features, die noch in Planung sind.
Viele Grüße
Kess
Hallo Kess,
Und wo wir jetzt wissen, was eigentlich gewünscht ist:
öhm... <spitzfindig> wo steht, daß dieses Feature hier gewünscht
ist?
<?m=125756&t=24136> (Du sagtest nicht, von *wem* gewünscht ...)
Ich schrieb nur, daß es tatsächlich nicht aufwendig sein dürfte.
Eben. Und das reicht mir, um es den Entwicklern *anzubieten*.
(Bzw. um die Erfinderin zu "stupsen", genau das zu tun ...
mach das mal ruhig selbst, Klaudia, es tut nicht weh. ;-)
Übrigens: nicht jede Idee muß auch umgesetzt werden.
Wenn ich mir die Ideenproduktion hier ansehe, dann wird mir Angst
um Bange um die wirklich wichtigen Features, die noch in Planung
sind.
Traust Du den Entwicklern keine sinnvolle Vergabe von Prioritäten zu?
Viele Grüße
Michael
Hallo Michael,
<?m=125756&t=24136> (Du sagtest nicht, von *wem* gewünscht ...)
stimmt. :-)
Traust Du den Entwicklern keine sinnvolle Vergabe von Prioritäten zu?
autsch. So wollte ich diese Aussage nicht verstanden haben. Obwohl die Gefahr natürlich grundsätlich immer besteht, sich zu verzetteln, glaube ich eher, daß die Qual der Wahl am Ende zu einem Overhead in jeder Hinsicht führen wird. Das alles erschlagende Forumsmonster.... Hm, spätestens dann brauchen wir ein Maskottchen für das Teil. Vorschläge werden noch angenommen *g*
Viele Grüße
Kess *die heute zu Gedankensprüngen neigt*
Hallo Kess,
Obwohl die Gefahr natürlich grundsätlich immer besteht, sich zu
verzetteln, glaube ich eher, daß die Qual der Wahl am Ende zu
einem Overhead in jeder Hinsicht führen wird.
Das alles erschlagende Forumsmonster....
Die Entwickler wissen das aber auch und werden an einem wartbaren Quell-
text interessiert sein.
Ich sehe das so: Wenn das zusätzliche Feature durch einen Schalter in
der Konfiguration und ein Print-Statement realisiert wird, also weder
eine Änderung von Datenformaten noch Programmieraufwand verursacht
und trotzdem etwas bringt, dann steigt die Chance auf seine Umsetzung
enorm. Umgekehrt würde sie stark sinken, wenn tatsächlich zusätzliche
Informationen zu speichern wären, weil das Feature dann mit bestehenden
und zukünftigen Features kollidieren könnte oder zumindest entsprechende
Abhängigkeiten entstehen würden.
Und genau deshalb habe ich in der vorherigen Diskussion so stark zwischen
der Einblendung innerhalb eines Postings und innerhalb der Hauptdatei
unterschieden, weil beides zwar ähnlich aussieht, aber ganz unterschied-
liche Auswirkungen auf die internen Abläufe und Strukturen haben würde.
Ich will Klaudia zuerst die einfache Lösung (mit dem günstigen Preis-/Lei-
stungs-Verhältnis) separat "anbieten", um zu verstehen, ob ihr das reichen
würde, bevor ich über die Implementierung der komplizierten im Detail
nachdenken möchte.
Wenn sie dann schon "nein" sagt und damit quasi diesen Teil des Feature
Requests freiwillig zurückzieht, dann sind die Entwickler schon mal schlau-
er als zuvor ...
Viele Grüße
Michael
Hallo Kess
öhm... <spitzfindig> wo steht, daß dieses Feature hier gewünscht ist? Ich schrieb nur, daß es tatsächlich nicht aufwendig sein dürfte.</spitzfindig> ;-))
Nirgends ... da hast Du schon recht ... aber ich muß mich in dem Fall Michael anschließen. Ich fände es auch nicht schlecht zu sehen von wie vielen "Lesern" ein Posting / Thread bisher gelesen wurde. Und auf die Archivierung hat das imho auch keinen Einfluss da niemand von den Besuchern des Forums sieht wie oft für dieses Posting / diesen Thread gevotet wurde. Also wo ist das Prob?
Übrigens: nicht jede Idee muß auch umgesetzt werden.
Volle Zustimmung ... aber muß deshalb gleich jeder Ansatz eines Verbesserungsvorschlages niedergemacht werden bzw. mit Hinweis auf FAQ oder ähnliches abgelehnt werden?
Wenn ich mir die Ideenproduktion hier ansehe, dann wird mir Angst um Bange um die wirklich wichtigen Features, die noch in Planung sind.
Dann solltet Ihr uns ( den usern ) einfach mal sagen was Ihr so plant. Damit könnte sich so mancher "Vorschlag" verhindern lassen.
Okay ... es wird dann zwar auch die "bitte nicht" oder "was soll das" schreier geben ... aber das gibt sich mit der Zeit auch.
Und wenn Ihr dem Anspruch ... Ein neues Forum das den Wünschen gerechter wird als bisher ... gerecht werden wollt so solltet Ihr imho nicht alles mit dem Hinweis auf die FAQ abblocken sondern offen für Anregungen sein, ob diese umgesetzt werden ....oder auch nicht ist ein anderes Kapitel.
Das Ihr es nie schafft allen gerecht zu werden ist klar ... irgend einer hat immer was auszusetzen. Und das Ihr sagt das geht und das nicht ist auch Okay. Das die Umsetzung von Ideen für Euch letzlich in Arbeit ausartet steht auch außer Frage.
Mich stört nur das ich den Eindruck habe das ihr erstmal alles abblockt. Ich mag mit meiner Meinung falsch liegen .... okay dann verbessert mich. Was ich jedoch aus den Postings der letzten Tage heraus lesen konnte war das ein Teil der Forumsteilnehmer, wie ich sich einige Änderungen wünschen.
Warum bezieht Ihr nicht einfach klar Stellung zu diesen Wünschen sonder redet immer nur um den heißen Brei herum.
Mir wäre es lieber zu wissen was Ihr vorhabt als immer wieder nur die "Standardantworten" zu hören.
Mit einen "so wollen wir es machen" kann ich besser zurechtkommen als mit einem " mal sehen".
So das musste ich jetzt einfach mal los werden ... auch wenn ich mich sonst nur selten an diesen Diskussionen beteilige - und auch nicht dafür vote.
Gruß
Jürgen
(der auch diese Posting via AOL übermittelt hat)
Hi,
Also wo ist das Prob?
Wenn Du Dein Leseverhalten danach ausrichten möchtest, dann würde Dir
eine Einblendung in der Forumshauptdatei mehr nützen als nur innerhalb
einer Posting-Anzeige.
Das aber würde bedeuten, daß die XML-Struktur der Hauptdatei bei jedem
Lesevorgang (!) eines beliebigen (!) Beitrags komplett neu geschrieben
(!) werden müßte. Das fände der Server nicht ganz so lustig ...
Dann solltet Ihr uns ( den usern ) einfach mal sagen was Ihr so plant.
Damit könnte sich so mancher "Vorschlag" verhindern lassen.
Mehr als immer wieder Links auf SourceForge setzen können die Entwickler
und Tester nicht tun ... welchen nehmen wir also heute?
https://sourceforge.net/tracker/index.php?group_id=21057&atid=121057
Das Problem ist halt, daß "technische" Diskussionen in SourceForge besser
aufgehoben sein könnten (weil sie dort von den Entwicklern gelesen werden),
während "politische" Diskussionen dort nutzlos und hier unerwünscht sein
dürften.
Nur leider können das die meisten "Ratgeber" schlecht auseinanderhalten ...
Mich stört nur das ich den Eindruck habe das ihr erstmal alles abblockt.
In diesem Punkt solltest Du zwischen dem Betreiber dieser Forums-Instanz
und den Programmierern der OpenSource-Forum-Software differenzieren. Einen
Wunsch technisch um- bzw. politisch durchzusetzen sind zwei Paar Stiefel.
Ich tendiere dazu, mir zuerst den Kopf über das technische Machbare zu zer-
brechen und die konkrete Forums-Instanz in erster Näherung zu abstrahieren.
Warum bezieht Ihr nicht einfach klar Stellung zu diesen Wünschen sonder
redet immer nur um den heißen Brei herum.
Lesen bildet: </selfaktuell/forum/faq/forumsfaq_1.htm#a5>
(der auch diese Posting via AOL übermittelt hat)
Ob ich wohl als nächsten feature request einen "forum washer" gegen solche
Werbeeinblendungen beantragen soll? (Hast Du wenigstens Aktien von denen?)
Viele Grüße
Michael
Hallo ihr,
(der auch diese Posting via AOL übermittelt hat)
Ob ich wohl als nächsten feature request einen "forum washer" gegen solche
Werbeeinblendungen beantragen soll? (Hast Du wenigstens Aktien von denen?)
den Teil muß ich auf meine Kappe nehmen, nachdem ich mich schon
öfters sehr "kritisch" über AOL (und den typischen AOL-User) ge-
äußert habe ;)
Jürgen nimmt mir es zum Glück nicht übel und hat mir übrigens auch
bei dem Problem mit der AOL-Bilderkompression weitergeholfen, was
Dich, Michael, ja auch interessiert hatte, wenn ich mich recht er-
innere.
Im navigator.useragent steht da immer AOL drin, wenn der Original-
Browser von AOL genutzt wird, brauchst Du nur auswerten und einen
Link zu einer speziellen Hinweisseite einbauen.
Wie gesagt, ich habe nicht´s gegen _alle_ AOL-User, sondern gegen
den typischen AOL-User, so wie _ich_ ihn mir vorstelle, was viel-
leicht auch nicht so völlig daneben liegt ;)
Ein AOL-User tritt seitdem in diesem Zusammenhang lieber anonym auf
(um meinen "Anfeindungen" zu entgehen *g*) und Jürgen sieht es eben
sportlich. Trotzdem hoffe ich, dass niemand von Euch Aktien vom
AOL-Netscape-Konsortium besitzt, da gibt es weissgott bessere
Möglichkeiten auf dem Markt.
Viele Grüße aus Dresden,
Stefan Einspender
Hi,
Meinst Du mit "Aufrufen" die Zahl der Lesevorgänge? (page views?)
Die wird gespeichert (weil sie Bestandteil des Voting-Verfahrens ist).
Diese Information anzuzeigen ist eine "politische" Frage, keine
technische.
Dass die Votings nicht gezeigt werden, kann ich sehr gut verstehen und bin auch
genau der selben Ansicht.
Aber es würde meiner Meinung nicht schaden, d.h. keinen beeinflussen, wenn man
nur die page views anzeigt. So kann es sein, dass die Nachricht drei mal gelesen
wurde und auch 3 mal gevoted wurde (100%).
Anders kann die Nachricht ja auch 100 mal gelesen worden sein und kein einziges
Voting erhalten haben. Oder würde man automatisch darauf schließen, dass eine
häufig gelesene Nachricht (ähm Posting) auch "wert" ist, gevoted zu werden?
Ich jedenfalls nicht.
Wie kannst Du aus dem Fehlen einer Antwort auf dessen Ursache schließen?
Natürlich kann ich nicht 100%zig sagen, warum. Aber ich kenne mein Postin und weiß
auch wie ich es formuliert habe (Titel, Text, tatsächliches Problem...)
Da kann ich doch schon sagen, ob ich das vielleicht doch unglücklich ausgedrückt habe,
ob's zu uninteressant, speziell oder zu schwierig gewesen sein könnte(!).
Man könnte es ja vielleicht mal versuchsweise einführen, nachdem man ein paar
Richtwerte vom jetzigen System bekommen hat. Ob sich's wirklich auswirkt oder nicht.
Viele Grüße,
Klaudia