Archiv verlassen und diese Seite im Standarddesign anzeigen : JBB Tray - Implement./Planung - Leute gesucht
moin,
ich hab schonmal einen aufruf gestartet. Allerding als x-te antwort auf den JBB Thread selbst, den seiner länge halber wahrscheinlich nur noch die wenigsten leute lesen werden. :)
Was ich such sind leute, die sich lust haben sich mit folgendem zu beschäftigen:
[quote]
JBB Tray (Joel's Bulletin Board - Tray)
Das JBB Tray (im folgenden einfach "tray") ist ein kleines, feines, aber effektives Spielzeug, wie es sich schon viele Power User von Foren und Boards sicher gewünscht haben. Eine möglichkeit ohne seine müde Hand und die Maus, oder sonstwas zu bewegen trotzdem immer auf dem laufenden sein, was es gereade so neues auf seinen lieblings Boards gibt, und ob vielleicht eine Antwort einen eigenen Post geschrieben wurde, oder neue persönliche Nachrichten eingegangen sind. Fuer diese Zwecke, die es fuer etwa Emails seit geraumer Zeit existieren, ist das kleine Programm, dass sein optisches Interface zur laufzeit auf eine Fläsche von 16x16 Pixel beschränkt, gedacht. Es versteckt sich, in der Version, die vom JBB Projekt (1) selbst veröffentlicht wird in der Win32 Version hinter einer kleinen signifikaten Lampe, die je nach Ereignis seinen Zustand von aus (keine Beitraege) zu an (Beitrag), oder verschiedenen Farben wechselt, wenn man z.B. auf eine wichtige Frage eine Antwort erwartetund in der Task Leiste sich neben der Uhr befindet. Also praktischer Weise dort, wo man sowieso ständig hinschielt.
[/code]
Die Entwicklung wurde Dez. 01 gestartet und laeuft noch. Allerdings ist es allein ein riesiges Projekt, dass sich aus mehreren Teilen zusammensetzt. Deshalb such ich fähige Leute, die lust haben mitzumachen.
Folgende Bereiche gibt es, bzw. spaltet sich das Projekt hin auf:
1. - bibliothek zum lesen schreiben einer configurationsdatei. (Status: funktionsfaehig/unstable)
2. - JBB Tray Config (JTC) [Abhaengigkeit zur config lib] (Status: hoffentlich Stable)
3. - Backend Implement. (Status: unvollstaendig/soweit stable)
4. - JBB Core (Planung)
5. - JBB Win32 Interface (Planung)
6. - JBB Linux Interface (X/Console) (im Gedanken)
7. - JBB Tray Config CGI
Eine kurze beschreibung des Bereiche:
1. Implementierung einer Bibliothek, die das schreiben und lesen einer Config. ermöglicht, wie sie etwas bei proftpd und apache zum einsatz kommen. Ziele sind geschwindigkeit und funktionalitaet. Besonders auf zweiteres leg ich grossen wert, bzw. auf die einfache schnittstelle der lib. Sollte man nicht unterschaetzen. Die funtkionen, die bisher verwendet werden sind sowas fertig. schreiben/ersetzen steht noch an. soweit aber stable.
2. benutzen des schnittstelle zum lesen und schreiben der config ... mehr ist das eigentlich nicht.
3. wie 2., allerdings noch mit grundaufgaben zum backend des boards. (abrufen des backends, parsen so weit erforderlich), aber auch recht easy. :)
4. Das zusammenfuergen der JBB Tray Config und Backends zu einer lib, die von Interface entwicklern genutzt wird. Abgleichen von Daten der beiden quellen, syncronisieren, ... . groessere Plaungsarbeit wuerd ich mal sagen.
5. Aufsetzen auf Punkt 4 und entwickeln eines Interface fuer Win32 Systeme.
6. wie 5, in der X version, in der console version hab ich mit das in etwas vorgestellt, dass das gnze als eine weiterleitung an den lokalen mailer daemon aggiert, weil neu nachrichten dort in der console angezeigt werden und dies ganz praktisch ist.
7. Die Config, weil nicht von den Interface entwicklern uebernommen werden soll, baut auf einen Browser auf, mit man alles machen kann. Schon allein wegen der möglichkeit schnell eigene Skins in HTML zu entwerfen, ... .
Programmiersprache ist C. Nicht Ansi, aber soweit, dass es auf Win32 und Linux Systemen kompatibles ist. Das heisst auch funktionen wie alloca koennen genutzt werden. Wers dann braucht. Allerdings, bis auf 5,6 und 6 nur funktionen, die auf beiden systemen existieren, oder ein equivalent haben. Beim CGI z.b. die Umgebungsvariablengeschichte.
Die Lizens ist GPL. Das Projekt ist teil des JBB (Joel's Bulletin Boards).
Einziger Mitarbeiter bin z.zt. nur ich und somit auch in dieser Sache Projektleiter.
---
Noch eine Sache gibt zu tun. Wer 1) PHP beherrscht und 2) mit dem vBB vertraut ist und die schnittstelle programmieren möchte (Backend), der möchte sich auch bei mir melden. Die Specs. stehen soweit schon. Testprogramme werden sofern nicht von anderen teilnehmern am Projekt von mir gestellt. :)
---
mails an e.tuli@gmx.de
links:
http://sourceforge.net/projects/jbb/ <- JBB Projekt auf SourceForge mit einer alten Version des JBB Trays. Wer mal kurz die Funktionsweise sich antun will.
www.joelh.de/jbb/foren.php <- Das JBB selbst
ftp://etuli.d2g.com/jbb alternativ zur sourceforge seite immer die neuste version des trays (nicht anders als die bei source forge zur zeit), allerdings mit dem aktuellen (ist zur. zeit nicht so) des backends und der source codes (die versions nummer hat sich um mehr als 100 erhöht. also nicht mehr ganz aktuell :) wer sie haben moechte, und sie bis dato nicht online sind, mail an mich. ich ungefähr bei v0.0.200)
http://www.joelh.de/jbb/topiczeigen.php?nr=613&seite=1 <- Orig. Dev. Thread auf dem JBB.
http://www.joelh.de/jbb/topiczeigen.php?nr=696&seite=1 <- Planung und entwicklung des Backend Standarts.
mfg Stefan
so ... letztes wochenende hab ich mich mal mit cgi queries und deren umsetzung beschaeftigt. Hab n bisschen programmiert ... *g* bisschen ... und ein modul geschrieben, weil ich es auch fuer andere dinge brauch, aber ebend auch beim backend modul viele probleme loesst. Also backend auch soweit drin von den benoetigten funktionen, waren auch eigentlich nur drei, und auch soweit stable. query modul soweit stable, wie es korrekt verwendet wird. hoff ich zumindest. urlcodec auch stable, soweit korrekt verwendet. Eigentlich fehlt nur dir NULL kontrolle ... . hab (query.c/h, urlcodec.c/h) mal auf den ftp gezogen (ftp://etuli.d2g.com/jbb/source/lastest/). Ich glaub es sind nur linux header drin. Muesstet ihr mal gucken, dass ihr, wenn ihr unter win kompilieren wollt, die sys/types.h ersetzt. bzw. euch da eine eigene schreibt. Sonst mach ich das auch noch, aber es tut zur zeit nicht not ... deshalb. Lokale funktion zum testen ist bei beiden dabei. Beim query modul, eher weniger, sollte jedoch noch nachgeholt werden. Die erlaeuterungen zu den funktionsflags stehen in der headerdatei.
viel spass
ps. eigentlich schade, dass sich niemand meldet ... woran liegts? zu viel schon fertig? zu komplex? hab heute durch gecated und es sind ca 7560 zeilen. mit headern. aus insg. 10 modulen. Bei denen schwank aber die groesse von 119 zeilen, bis 2536 zeilen, beim groessten. Also ihr koennt ja auch eine kleinere aufgabe uebernehmen, wenn euch das zu gross erscheint. :) daran solls nicht scheitern. Und die grossen module waren ja auch nicht ploetzlich da, sondern sind nach und nach immer groesser geworden. ;)
stefan
JBB ist halt einfach noch nicht so verbreitet, dass es viele anspricht.
wie siehts mit der portierung auf vbb,phpBB, etc. aus ?
oder hast du gar keine "Metaebene" benutzt sondern einfach programmiert ?
also es sieht so aus, dass sich das ganze zentral in zwei themen einteilt. Einerseits die entwicklung des trays und andererseits die entwicklung eines protokolls fuer die kommunikation zwischen dem board und dem tray. Dabei ist das protokoll, weder vom tray, noch von einer festen boardstruktur, oder sprache abhaengig. Das war mit das zentrale ziel. Also waere eine implementierung fuer hier kein problem, und das ist auch geplant, aber die leute fehlen, die lust und kenntniss von dem board haben und von php. Auch auf systemen wie parsimony.net waer die umsetzung moeglich und es wurde dran gedacht, strukturen, wie diese einbinden zu koennen. :) Also kompatiblitaet ist auf alle faelle gegeben. Es ist nicht so, dass das jbb das einzige waer, um das es sich hier dreht.
stefan
moin,
hat einer von euch ne ahnung, ob es erstens boards gibt, die fuer ihre categorien keine id's verwenden? geh ich bisher von aus. Und zweitens, die fuer ihre posts, oder foren selbige auch nicht verwenden, oder foren strukturen, die nur relative ids fuer posts verwenden? Z.b. http://host/board-cgi/show_topic.cgi?forum_id=2&topic_id=1 .
ersteres ist wichtig, weil ich grade beim programmieren der vergleichsroutinen drauf gestossen bin. Bisher hab ich irgendwie angenommen, dass ich das schon geloesst hab. War auch lange zeit zwischen den teilen. Das "problem", also es ist auf alle faelle loessbar, wuerde so aussehen, dass ich zwei stukturen hab, von denen ich einlese. eine fuer die daten des backends und eine fuer die der config des programms selbst. Die vom backend gibt mir die id und den namen. die der config den command, andersgesagt die policy, entweder accept, oder deny, und die id und den namen. Dabei ist der name immer optional.
#define JTC_CATEGORY_FMT "<category %p [%hu] [%p]>",\
sizeof(struct jbb_tray_config_category_block),\
" [lastpost] %lu",\
JTC_FORUM_FMT,\
"</category>
/* <category $command $id $name> */
fuer das einlesen der config fuer alle categorien. [] bedeuten, dass die eigenschaft optional ist, bzw. ein argument. <> sind intern fuer den anfang und das ende des blocks. Alles mit % sind formatangaben nach ansi scanf. h fuer short. l fuer long. u is unsigned, p ist pointer (weiss garnicht, ob ansi, aber wird auch nicht mit scanf gehandlet. ebendso wenig wie %s, das wuerde copy eines string bedeuten und wird behandelt wie %as unter linux mit scanf).
das format fuer das backend.
#define CATEGORY_FMT "<category %hu [%s]>",sizeof(CATEGORY),\
FORUM_FMT,\
"</category>"
*denk* irgendwie fehlt das lastpost ... aber kann auch spaeter rein. mal so nebenbei.
hier ware es dann <category $id $name> und name optional.
das problem stellt sich jetzt durch die anzahl der argumente dar, die entweder gelesen werden, oder nicht.
Normalerweise wird es so gemacht, dass das backend eine category wie folgt ausgeben wuerde
<category 45 "peterchens lustspielchen"
# foren
</category>
nur dumm, wenn jetzt keine category id existiert, weil die pflicht ist. das wurde bedeuten, dass das backend irgenwas anders dafuer einsetzten muesste. Da 0 wegfaellt, wurde ich eine andere magische zahl sagen, aber das ist unschoen. Weglassen, z.b. indem wir einen pointer statt das einlesen einer zahl nehmen geht auch nicht, weil der name dann pflicht sein muss und ein argument, dass nicht am ende der liste steht, kann man nicht weglassen. das umdrehen wuerde klappen, also <category %s %hu> zu lesen wuerde gehen, aber dann wurde sich ein anderes performanceproblem fuer board mit category id auftun, weil sie jedesmal eines namen senden muessten, bzw. "" als platzhalter und das ist auch unschoen. Vielleicht, indem man einfach 2 strukturen mit 2 verschiedenen formaten benutzt, die dann durch ein flag vom backend bestimmt werden. Also flag wenn id nicht vorhanden und dann wird eine alt. struktur verwendet. Da wuerde allerdings sehr viel mehr aufwand bedeuten. Es muessten nicht nur die strukturen, sondern auch die funktionen veraendert werden, die darauf zugreifen. Zumindest bei zwei verschiedenen, weil wenn das format auch die struktur selbst gaendert werden muss. das liegt an der funtion zum lesen der config. und gaendert wird die nicht, weil die sinn macht. Aber selbst dann. ein gelesener integer muesste einen wert bekommen und das bringts auch nicht wirklich. dann wieder die magische zahl. Zwar muesste nicht mitgesendet werden, was traffic spart, aber das machts auch nicht besser. Man koennte auch vom backend verlangen. Naja ... geht schon. das flag, koennte man dann ja in die categoryx reinnehmen, wurde dann beim suchen ebend verwendet werden. muessten ja garnicht zwei strukturen sein. oder *denk* ... naja ... muesste das backend 0 und das flag setzen, dass 0 ebend nicht beachtet wird. also
<category $id $name $use_id> id koennte 0 sein, name muss dann stehen und use_id wurde auf false (0) stehen. das koennte man dann auch einfach auf forum, ... portieren. Hey ... gefaellt mir! :) und ude_id waer dann optional und default maeesig 1 (kann man im format angeben), damit der name nicht vorkommen muss und dann die id verwendet wird.
"<category $hu [%s] [$hu](1)>"
schoenes ding.
*g* zweites problem mit der jt_config. Eigentlich das selbe problem. Nur das es da eigentlich noch anders sein sollte, dass man direkt alles weglassen kann. Grund dafuer sind anonyme categorien/foren/topics, die stelvertretend fuer alle nicht aufgefuehrten "einheiten" stehen. Z.B. wenn man aus einer category nur ein topic haben moechte. dann sollte man
<category DENY>
<topic ACCEPT 54>
</topic>
</category>
benutzern koennen um das auszudruecken. Hier auch wieder das format fordert eine id. Wenn die id wie oben nicht gegeben ist, muss ein wert zugewiesen werden. 0 geht nicht, weil es eine gueltige id sein koennte. eine magic number kommt in frage, aber ist unschoen. Koennte man eigentlich auch so machen, dass man ein extra arg. reinnimmt. also um anzuzeigen, ob es sich um eine anonyme category handelt. dann waer ds problem geloesst. hier koennte man aber auch versuchen das ganze ueber einen pointer zu loesen, weil wenn die category anonym ist, sie auch keinen namen hat. Nicht wie es beim backend ist, das eine das andere ausschliesst. Schwer zu verstehen, wenn man nicht die hintergruende hat. ich weiss. :)
Also ich als format wahle
<category %p [%p] [%p]> statt die id direkt als integer zu lesen, also den pointer, welcher null, ist, wenn das argument optional ist. Sofern nicht anderes gegeben ist zumindest. also wenn "<category DENY>" gelesen wird ist durch den null pointer weiss, dass die category anonym ist. Und wenn der pointer des namen auch null ist, dass auch kein name gegeben ist. hmm ... muesste auch beachtet werden. doch ... obwohl ich oben was anderes meinte. *sucks* ... aber trotzdem ... geht so :). Das problem bei dem pointer, dass er nicht einfach als integer verwendet werden kann, also irgendwie noch umgewandelt werden muss. Auch nicht schoen. Und eigentlich sollte es sowas nicht geben. Ein flag ... keonnte man machen und ist denke ich am schoensten. Das flag allerdings diesmal mit an den anfang.
<category DENY 1> 1 als anzeiger, dass es sich um eine anonyme category handelt. oder null, falls es sich um eine non-anon. category handelt. dann die id und den namen, sofern gegeben. Und um dann das ganze mit der "name vorhanden, aber id nicht" aus dem weg zu raeumen, wurde wie beim backend ein flag am ende folgen.
<category DENY $anon? $id $name $use_id?>
anony koennte man eigentlich optional machen und default auf anon setzen. Dann haetten wir das ziel erreich. *g* <category DENY> perfekt. Dann alles andere optional.
"<category %p [%hu(1)] [%hu] [%p] [%hu]". Nur das dumme dabei .. *g* .. eigentlich war es mein ziel, grade die config human readable zu halten. Deshalb verwende ich auch z.b. DENY und nicht 0, oder 1 fuer ACCEPT. hmm ... *g* naja ... schicksal. koennte man auch ANON nehmen statt 1. Aber dann muesste ich es wieder im nachhinein bearbeiten und das suckt auch. muss ich bei ACCEPT und DENY auch und irgendwie ... naja ... egal. Vielleicht faellt ja wem was besseres ein. Hoffentlich hat jemand ueberhaupt das problem verstanden und allg., was ich hier so laber. :)
stefan
moin mal wieder,
ich hab mir jetzt ueberlegt, dass ich es mache, wie oben erwaehnt mit den flags. Das human readbale problem loese ich durch eine art praeprozessor, der die symbolischen angaben umwandelt. Haette ich fuer ACCEPT und DENY sowieso machen muessen "und das ist auch gut so" :).
demnach sieht die formatangabe (im quellcode) fuer die jt(jbb tray) config so aus.
/*
* Bezeichnungen
*
* flag
* Ein true, oder false wert, der entweder die symbolischen Werte
* "TRUE", oder "FALSE" haben kann, oder die numerischen Werte
* 1, oder 0.
*
* Block
* Eine Category, ein Forum, oder ein Topic Block.
*
* $command
* Ist die policy des Blocks, welche entweder die symbolischen
* Werte "ACCEPT", oder "DENY", oder die numerischen Werte
* 1, oder 0 annehmen kann.
*
* anonyme Bloecke
* Anonyme Bloecke sind jene, die Stellvertretend fuer alle
* nicht aufgefuehrten Blocke stehen, die bestimmt sein koennten.
*
* bestimmte Bloecke
* Bestimmte Bloecke sind jene, die eine klare identifizierung
* etwa durch eine ID und/oder einen Namen haben.
*
* $is_anon (flag)
* Zeigt an, ob der Block anonym (true) ist, oder bestimmt (false).
*
* $id
* Gibt die Id des Blocks realtiv, oder absolut zu einem anderen
* Block an.
*
* $name
* Der Name des Blocks.
*
* $use_id (flag)
* Gibt an, ob die angegebene $id verwendet werden soll, um den
* Block zu identifizieren. Ist dieses flag false, muss
* fuer eine identifizierung der $name gegeben sein.
*
*
* Category
*
* Das Format der Category ist:
*
* <category %p [%hu] [%s(1)] [%p] [%s(1)]>
*
* <category $command [$is_anon?] [$id] [$name] [$use_id?]>
*
* Der default Wert fuer $is_anon ist true, wenn nicht anders gesetzt.
* Der fuer $use_id ebenfalls auf true, sofern nicht anders gesetzt.
*
*
* Forum
*
* Das Format des Forum ist:
*
* <forum %p [%s(1)] [%hu] [%p] [%s(1)]>
*
* <forum $command [$is_anon?] [$id] [$name] [$use_id?]>
*
* Der default Wert fuer $is_anon ist true, wenn nicht anders gesetzt.
* Der fuer $use_id ebenfalls auf true, sofern nicht anders gesetzt.
*
*
* Topic
*
* Das Format des Topic ist:
*
* <topic %p [%s(1)] [%hl] [%p] [%s(1)]>
*
* <topic $command [$is_anon?] [$id] [$name] [$use_id?]>
*
* Der default Wert fuer $is_anon ist true, wenn nicht anders gesetzt.
* Der fuer $use_id ebenfalls auf true, sofern nicht anders gesetzt.
*
*/
%s fuer die flags, weil das modul fuer die config einerseits so keine pointer handeln kann, weil das nur zu speicherzugrifffehlern fuehren koennte/wuerde und kein %hu, weil man darin keine pointer aufnehmen koennte, wie bei "ACCEPT", oder ebend den anderen symbolen verlangt.
fuer das backend.
7.2 <category>
Der CATEGORY-Block, in Deutsch Kategorie-Block, darf nur im
<jbb> Block auftreten. Er steht für die einzelnen Foren des
Boards. Seine Syntax lautet
<category $category_id [$category_name]
[$use_id]>
...
</category>
Das erste Argument ist die ID der Kategorie. Sie ist Pflicht,
kann aber durch die Nutzung der use_id Arguments so geschaltet
werden, dass sie nicht beachtet wird, bzw. einfach nicht
verwendet wird.
Das zweite Argument ist der Name der Kategorie, der optional
ist.
Das dritte ist das use_id Argument, dass angibt, ob die
angegebene ID verwendet wird, oder nicht. Das ist vor allem da
noetig, wo keine ID vorhanden ist. Das use_id flag kann die
Werte "TRUE", "FALSE", oder die
nummerischen true, false Werte 1, oder 0 annehmen. Je nach
Wunsch. Der default Wert fuer das flag ist true, die ID wird
also standartmaessig verwendet und das flag kann weggelassen
werden.
Ich werds auch noch wie oben mit den allg. Bezeichnung machen, weil ich sonst immer wieder alles erklaeren muss, weil fuer forum und topic muss das auch rein.
naja ... aber erstmal wieder was programmieren und mich an das us layout gewoehnen ... is echt ziemlich scher. besonders anfuerungszeichen und z un y machen mir da probleme. Wird wohl etwas langsamer vorangehen alles. :) aber wird schon klappen.
stefan
ubb verwendet das system:
ubb.cgi?ubb=showpost&f=1&t=0000001
finde ich nicht gut, kann ich aber nichts dran aendern. Nicht gut, weil das heisst, dass wenn das board nur topics sendet
<jbb>
model topic
<topic 34 "topicname">
</topic>
</jbb>
die forum id fehlt. Das bedeutet wiederum, die muss woanders herkommen, in diesem fall gesendet werden. Nun gibts die moeglichkeiten, dies einmal in den header des topics zu nehmen, halt ich aber fuer eine schlechte idee, weil dies probleme fuer andere boards bringt (wuerde am anfang pflicht und am ende alle anderen argumente des headers zu pflicht machen), die zweite ist, dass die forum id, als eigenschaft ins topic kommen.
<topic 34 topicname>
fid 2
</topic>
Gefaellt mir ehrlichgesagt allerdings auch nicht, weil dies bei vielen posts nur unnoetig transfervolumen kostet und bei der haelfte bestimmt nicht noetig gewesen waere, weil sie doppelt, oder n-fach vorkommt, oder drittens, in diesem fall wird es plicht, dass auch das forum angegeben wird. Also das alleinige senden von topic bei boards mit relativer post id verboten wird, weil dies unmoelgich wird, in dem fall, da die fid fehlt.
<jbb>
model "topic forum"
<forum 2>
<topic 34 topicname>
<topic>
</forum>
</jbb>
Koennte man einen stdwert setzen, macht aber ... *denk* keinen sinn, weil das auch in die url koennte. oder? auf jeden fall nicht wirklich notwendig und wuerde denk ich auch nur zu dummen fehlern auf seite des benutzers fuehren. Obwohl ... *zweifel* ... man koennte es beispielsweise so handlen, das bei einfachen non-boards, oder boards mit einem forum nur eine id haben ... warum dann immer mitsenden? Ich werds mal reinnehmen, und im falle keiner fid dann die std. fid nehmen lassen. Schaden wird es denk ich nicht. Was mit an der dritten methode nicht gefaellt ist eigentlich die tatsache, dass es bei kleinen boards mit kleiner frequentierung auf vielen foren viel traffic entsteht die daten zu senden! deshalb wuerd ich mich spontan fuer eine loesung zwischen zwei und drei entscheiden. Gefaellt mir am besten und gleichen sich von ihrem probleme und vorteilen aus (viel traffic/viele posts zu viel traffic/viele posts). Lass ich die boardadmins und entwickler entscheiden, wie sie das handlen wollen, mit den gegebenen moeglichkeiten.
stefan
so ... weiteres problem. Kennt ihr das Code-Schnipsel Forum? Nicht? Schwach! :) Dann aber das Archivforum von hier, wo alles gescheiterte, oder fertige, oder sonstwas reinkommt. Was faellt auf? Diese "Foren" stimmen nicht mit der Struktur eines "normalen" Boards ueberein, wie ich es mit vorgestellt habe. Heisst, dieses Forum an sich ist eine Kategorie, die die Eigenschaft hat, wieder Foren zu haben. Loesbar fuer n-verschachtelungen, indem man einfach neben topics als Eigenschaft fuer foren noch weitere foren nimmt.
Als struct dann ...
<jbb>
model "category forum topic"
<category>
<forum 3>
<topic 45 "topic in forum (fid 3)">
</topic>
<forum 6>
<topic 67 "to...">
</topic>
</forum>
</forum>
</category>
</jbb>
also jbb->category->forum->forum->topic . Zwei gedanken trotzdem.
Da es eigentlich problematisch ist, oder zumindest fraglich immer alle unterforen zu verlangen, in hinsicht auf die struktur, waere es ratsam die tiefe der foren zu begrenzen, um traffic zi sparen. Da dies aber nicht beim model gemacht werden kann, duch hinzufuegen eines begriffs, muesste man sich was anderes ueberlegen ... weil es sind foren in dem sinne. Vielleicht per index.
<jbb>
# forum#subs
model "forum0"
</jbb>
also forum, um anzueigen, das foren ueberhaupt gegeben sind und die zahl als anzeiger, wieviele unterforen es gibt, falls es welche gibt ( >0 ). *druebernachdenk* ... Ist eigentlich gut so.
Gibts noch mehr solche spielerein, die man unbedingt beruecksichtigen sollte? Was sonst von innovativer seite der boardentwickler kommt, koennen die auf das bisherige emulieren. :P
edit: ich hab mal geguckt. das vbb verwendet, von der nummerierung der unterforen kein anderes system. unterforen werden einfach als normale foren gesehen. Obiges koennte man also eigentlich weglassen, da es aber vielleicht nicht ueberall gleich gehandlet wird, und weil man sonst sich vielleicht verirrt und ein forum woanders sucht, mach ichs so wie oben geschrieben. ;)
stefan
so ... wieder 2 lustige ideen gehabt *g*.
erstere handelt von meinen fast lieblingsthema. dem sparen von traffic. Idee war das backend per gzip, oder was grad da ist zu packen und dies anstatt der plain daten zu senden. Macht sinn.
zweitere hat mit erster zu tun, weil ersteres die cpu verzehrt, auf hochfrequentierten board, wenn 20k leute permanent das backend abrufen und jedesmal die erzeugte backendausgabe mit gzip gepacket werden muss. Loesung ... man machts nur einmal ... problem ... man ist nicht immer uptodate und man kann, bei bestimmen benutzterdaten wie pn's dies nicht so uebertragen, weil daten eines mitglieds an 20k leute senden macht irgendwo nicht den sinn, den die idee braeuchte *g*. :) also ... koennten wir es so machen, dass wir dies, wenn es dann so kommen sollte, das der fall eintritt, zwei mal eine anfrage reinkommt. Muesste dann durch ein azeiger in der modeleigenschaft gemacht werden, und das jbbtray muesste dann gucken, ob es ueberhaupt private daten braucht und verlangt werden, und ob dies das backend des boards tut.
Mit der Zeit ist dies kein problem. Der server kann auch eine erstellte und gepackte ausgabe von vor 20 stunden senden und das tray wuerde immernoch dankend annehmen und mit der lokalen zeit verknuepfen, weil das tray das nicht interessiert.
stefan ... blabla
zweiteres, gefaellt mir irgendwie nicht mehr, seit dem ich irgendwas durchdacht hab, was mir grad irgendwie nicht mehr einfaellt. Es hatte nicht damit zu tun, dass bei kleinen backend ausgaben die http header zu sehr ins gewicht fallen, und es hatte irgendwas programmiertechnisches zur folge ... *denk* ka. Aber die http header sind schon ein grund das irgendwie anders zu loesen. Ich hab mal bei lou angefragt, ob es ueberhaupt geht und geht hier, heisst, woanders kann es auch gehen. Deswegen sollte es auch rein. *denk* ich komm einfach nicht drauf!
naja ... irgendwann dacht ich dann, ich koennt die sachen in das backend als block nehmen.
<jbb>
<packed gzip>
ASCII 8 bit code
</packed>
</jbb>
das furchtbar dumme ist, diese sorte von struktur nicht mit dem conf modul, das das gesamte parsen der configs und des backends uebernimmt, gelesen werden kann. Zurecht. Und das wird nicht geaendert. Alternativ koennte man diese Struktur mit einem weiteren Modul lesen ... ist aber "dreckig" und das conf modul wuesste trotzdem nicht, was es mit dem code machen sollte.
Dann dacht ich, ich koennte ja die daten davor, oder dahinter schreiben. also
ASCII 8 bit code
<jbb>
...
</jbb>
waere moeglich und ein problem, das im moment mit der performance des conf moduls in situationem mit enorm langen zeilen besteht, koennte einfach geloesst werden (im moment liesst es immer erst die ganze zeile, anstatt direkt das erste zeichen zu ueberpruefen, ob diese korrekt ist). Wuerde ichs dahinter machen, wuerde es denk ich am einfachsten gehen. Das parsen der conf stoppt nach dem parsen des </jbb> tags. also
<jbb>
...
</jbb>
ASCII 8 bit code
fuer die angabe des inhalts der daten des backends wuerde dann ins model packed, oder sowas kommen. Oder eine extra eigenschaft, die direkt noch die methode angibt. Bei win bspweise. pkunzip und unix systemen gzip.
Oder man koennt die dateienals tar ball aus zwei dateien uebertragen. Eine gepackt, die andere nicht. tar gibts sowohl fuer unixe, als auch fuer windows, kostet aber wieder cpu zeit. schade! ;) Obwohl mehr als das ganze mit php zu machen denk ich auch nicht, wenn nicht sogar weniger. mal ausprobieren.
*denk* ... was noch? 2 dateien, nochmal probieren, ob das gehen koennte. ... naja ... jemand andereres noch eine idee, wie man einerseits vorbereitete, gepackte daten, die fuer alle mitglieder zugaenglich sind und daten, wie beispielsweise ueber pn's in plain uebertragen koennte, ohne dafuer 2 dateien zu nehmen? Also eine *g*. ueber http. Vielleicht schlecht, weil ihr euch das nicht so vorstellen koennt, wie die conf arbeitet. Ich hoff einfach, das trotzdem was kommt.
ps. ich fuehl mich als alleinunterhalter ... aber dieses aufschreiben der gedanken kommt irgendwie kreativitaetsfoerdernd. :)
stefan
Hallo,
Ich weiss nicht ob dein Projekt vieleicht schon zu weit fortgeschritten ist für meine Anmerkung, aber das kannste sicher selbst entscheiden *g*
Kennste XML?
deine struktur...
<jbb>
model "category forum topic"
<category>
<forum 3>
<topic 45 "topic in forum (fid 3)"></topic>
<forum 6>
<topic 67 "to..."></topic>
</forum>
</forum>
</category>
</jbb>
..würde etwa so aussehen:
<jbb>
<category>
<forum id="3">
<topic id="45" heading="topic in forum (fid 3)">Das ist ein Post</topic>
<forum id="6">
<topic id="67" heading="to...">Das ist ein Post</topic>
</forum>
</forum>
<forum id="4">
<!--gezipte daten/ sonstiger binärer Kram (z.b. Images)-->
<![CDATA[
001100011001110011011120011101101
011000110011100110111200111011011
001100011001110011011120011101101
011000110011100110111200111011010
100110001100111001101112001110110
011000110011100110111200111011010
110001100111001101112001110110100
011001100011001110011011120011101
]!>
<!--nicht wundern! Das ist die neue trinäre CPU generation *eg*-->
</forum>
</category>
</jbb>
Vorteile:
es gibt schon fertige Parser.
ist W3C Standart
human and machine readable
einfach zu erweitern (Elemente die dein Code nicht kennt beachtet er nicht)
da standart, gibt es schnittstellen zu diversen DB's
einfache, schnelle Transformation in HTML mit XSL-T
Im neuen self-html ist eine gute Einführung in XML zu finden. An Ressourcen über XML gibt es wirklich kein Mangel, wird ziemlich Gehypet (Schlipsträge *kotz* reden von Sachen die sie nicht verstehen)
Parser gibt es wohl für alle Sprachen und Systeme. Selbst MS hält sich recht gut an den Standart. Ich kenne nur den MS Parser (habt wohl schon mitbekommen das ich bei'nem MS-Knecht schaffe? :) Der Parser sind Klasse! Es gibt zwei Varianten. Einmal ein DOM (Document Object Model)
ähnlich dem Model von HTML.
Die zweite Variante heist SAX(Simple Api for XML). Es ist für grössere Daten Mengen die schnellere, da es nicht erst alles parsen muss bevor man damit arbeiten kann. SAX feuert wärend des parsens Events. Auf die man dann
reagieren kann/muss. Eine etwas anderes Design als herkömmlich aber nach erste Erfahrungen damit, gefällt es mir recht gut.
Naja vieleicht ist es ja was für dich :)
moin,
ich hab das format fuer die config, an die allg. eigentlich gueltige methode von config dateien, wie sie etwa von proftpd unter linux verwendet werden, angelehnt. Unterschiedlich sind lediglich die randbedingungen, wie einleitender tag, was bei meiner variante (noch, keine ahnung, obs raus kommen sollte) pflicht ist.
die unterschiede liegen ebend darin, dass ich ohne niedergeschrieben standart arbeite, lediglich, was mir grade in den sinn kommt ;), xml ein anderes verfahren fuer die eigenschaften verwendet, was ich nicht so klasse fand, weil es einfach unnoetig ist (name=value). Wuerde auch bei 3, 4 kombinationen nicht den sinn machen, den es vielleicht in html macht, wo man wirklich viel optionen hat und keine moeglichtkeit mehr hat es sinnvoll zu gestalten, ohne den verwendungszweck fuer einen wert anzugeben.
der parser ist nicht das problem. Damit hab ich im dez. angefangen und der steht soweit. Aber bei XML das problem, dass ich nicht weiss, inwiefern XML da routinen liefert, was allg. irgendwo sowieso dafuer spricht, selbstprogrammiertes zu verwenden, was man auch spaeter benutzen kann! Das war mir wichtig. :) Wenn ich einen parser, der schon steht nehmen wuerde koennte ich weniger veraendern. lizens- und funktionalitaetsbedingt. Ich hab z.b. eine funktion, mit der kann ich in dynamische strukturen einer ganzen datei lesen. Nicht gegebene Bloecke und eigenschaften, die vorkommen werden auch uebersprungen. Der Aufbau der Struktuen wird dabei wie bei scanf mit formaten und was noch rein muss mit byte sprungmarken gemacht (ohh ... c++ler werden mich dafuer bestimmt hassen *g*). Das ist enorm praktisch, hab aber auch mit am laengsten gedauert.
es sieht fuer das backend, wenn ich den teil durch den proprocessor jage so aus.
if(conf_parse(f,&c,"JBB" ) == 0 ){
if(conf_getlblock(c.c_root,0,&b->b_jbb,
"<jbb [%s]>",
sizeof(struct bae_jbb),
"[title] %s",
"[time] %lu",
"[interval] %lu",
"[model] %s",
"[phrase] %s",
"<category @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_category),
sizeof(union bae_bflags),
"<topic @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_topic),
sizeof(union bae_flags),
"</topic>",
"<forum @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_forum),
sizeof(union bae_flags),
"<topic @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_topic),
sizeof(union bae_flags),
"</topic>",
BAE_FORUM_FMT,
"</forum>",
"</category>",
"<forum @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_forum),
sizeof(union bae_flags),
"<topic @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_topic),
sizeof(union bae_flags),
"</topic>",BAE_FORUM_FMT,
"</forum>",
"<topic @+x %ul [%s] [%s(1)]>",
sizeof(struct bae_topic),
sizeof(union bae_flags),
"</topic>",
"</jbb>",((void *)0) ) > 0){
ret = 0 ;
}
conf_free(&c);
}
(so vielleicht etwas unuebersichtlich ... sieht aber in den header gekapselt einfacher und verstaendlicher aus :))
also beides bietet vorteile, aber vorgefertigte programmteile sind bei mit kein vorteil beim programmieren. :) trotzdem ... die idee ist naheliegend, nur irgendwie doch schon teilweise unpraktisch und zu spaet ... nie ist etwas zu spaet.
nochmal drueber nachgedacht, kam ich auf den gedankenfluss, dass das problem an einer datei ist, dass es nicht moeglich ist diese auf einem proxi bereitzustellen, weil trotzdem teil der immer gleich ist, andere teile unterschiedlich sein koennten und wahrscheinlich sind ... that's life. Mal gucken, ... wird schon werden. :) Liegt hinten an, hat niedrige prioritaet und reicht, wenn es in einr spaeteren version reinkommt.
stefan
hey ... ich weiss wieder, warum zwei dateien ein "problem" sind. Die Routinen zum parsen/wandeln/abgleichen muessten alle samt zweimal durchlaufen werden und es besteht ein problem darin, dass zwei datein das zeitgefuehl des programms durcheinanderbringen wuedern, wenn die eine aelter als die andere waere. Und wuerden beide gleich alt sein, braeuchten wir keinen proxy support und so denk ich, ich werde eine datei nehmen und damit boesswillig in kaufe nehmen *g*, das proxz support nicht drin sein wird. :)
eine routine zum parsen von byte code wird dann in die conf eingebaut, wie oben in knt's xml beispiel.
<packed gzip>
^bytecode 344 # content-lenght
&*&JGFDFG%^#$%65RGert-$5... # 344 bytes
</packed>
so irgendwie.
stefan
hey ... ich werds unter anderem so implementieren, dass man die daten beim parsen der config aus einer anderen datei laden kann ... . Das loesst alle probleme auf einmal =).
.conf datei
<jbb>
binary {extern:local:/abspath/binary.file}
backend_gipped {extern:http:proxy.joelh.de/backend.gz}
</jbb>
es wuerde dann von der conf direkt so gelesen werden, als wenn das eine datei ist. Je nach methode wuerde eine datei eingebunden werden. Find ich gut ... :).
stefan
Doomhammer
29.08.2002, 19:29
ich versteh ja nicht viel von php aber ich hab auch schon ein kleines board geschreiben, zwar ohne irgendwelche admin optionen (fast keine), meine frage: Wieso braucht man ein Phaser ? Geschwindigkeit ?, Übersichtlichkeit ? ?????
? weiss nicht so genau, was du jetzt meinst, aber du brauchst fuer das programm das den computern der benutzer einen (code)teil, der daten aus einer datei
z.b.
<jbb>
<topic 123 "hallo welt">
</topic>
</jbb>
in eine entsprechende Struktur liesst, die das programm weiter verarbeiten kann. Dann ist dann der parser (analyizer), der das uebernimmt. Ohne wuerde es nicht gehen. :)
stefan
Doomhammer
29.08.2002, 23:27
ach soo ... ich dachte du woltest es in php schreiben
Kann man die Tray eigentlich irgendwo für Linux downloaden ?
praktisch ja ... theoretisch nicht. *???* Halt nur fuer die console, wie ich es hier teste. Muesstest aber erstmal dein backend neu einrichten (kann dir das mal schicken, dass ich zum testen verwende). Sonst das tray heut ungern, weil ich grad das interface fuer die gui implementiere und er irgendwo anfaengt zu haken. Weiss aber noch nicht genau wo.
toxic ist bei der 'erstmal' windows gui bei. Die Version ist allerdings auch schon "alt". Deshalb und weil der teil der main enorm gewachsen ist, muss nu das interface her.
so sieht das ganze dann ungefaehr aus.
stefan@blackbox:~/jbbtray/jbbtray$ ./jbb_demo webreeze.conf
jbb_demo:
built: Sat Nov 16 23:10:55 CET 2002
inf> events: 0x0003
inf> aktualisere die jConfig (file:"webreeze.conf")
inf> aktualisiere die jBackends
inf> Board (ID): "webreeze.de"
inf> Title: "jbb 0.8.1"
inf> URL: "http://www.webreeze.de/***"
inf> Username: ""
inf> Interval: 30
inf> Timestamp: 1037463357
inf> Backend Infos:
inf> Interval: 30
inf> Timestamp: 1037485343
inf> deadline: 30
inf> events: 0x0003
inf> aktualisere die jConfig (file:"webreeze.conf")
inf> aktualisiere die jBackends
inf> Board (ID): "webreeze.de"
inf> Title: "jbb 0.8.1"
inf> URL: "http://www.webreeze.de/***"
inf> Username: ""
inf> Interval: 30
inf> Timestamp: 1037485343
inf> Backend Infos:
inf> Interval: 30
inf> Timestamp: 1037485373
inf> deadline: 30
(sieht einfacher aus, als es ist. :D)
schlechtes beispiel ... reseten wir mal den timestamp ...
inf> events: 0x0003
inf> aktualisere die jConfig (file:"webreeze.conf")
inf> aktualisiere die jBackends
inf> Board (ID): "webreeze.de"
inf> Title: "jbb 0.8.1"
inf> URL: "http://www.webreeze.de/***"
inf> Username: "etuli"
inf> Interval: 30
inf> Timestamp: 0
inf> sende initalisierenden timestamp 0 ...
inf> Backend Infos:
inf> Interval: 30
inf> Timestamp: 1037485610
Sie haben um 23:59:59 auf das Topic "no-name" (id:2) geantwortet
Sie haben um 23:59:59 auf Ihr Topic "no-name" (id:3) geantwortet
Sie haben um 23:59:59 auf Ihr Topic "no-name" (id:4) geantwortet
inf> deadline: 30
ml: there are 0 leaks (0 bytes) in your code!
die uhrzeit ist falsch, weil ich zu dumm zu php bin. no-name sollte eigentlich der name des topics sein. Hab ich wohl im interface noch nicht gemacht.
stefan