2006-03-24T00:25:51 *** birkenfeld has quit IRC 2006-03-24T09:19:13 mitsuhiko: wow, habt ihr ziffern auch schon in klassen gewrappt? :) 2006-03-24T10:32:43 xorAxAx: die IP? ja!!! 2006-03-24T10:56:31 *** tux123^school has joined #pocoo 2006-03-24T14:11:24 *** birkenfeld has joined #pocoo 2006-03-24T14:18:07 moin birkenfeld 2006-03-24T14:18:14 moin mitsuhiko 2006-03-24T14:21:52 * mitsuhiko ist jetzt mal mit dem Hund weg 2006-03-24T16:08:01 *** tux123^school has quit IRC 2006-03-24T16:08:32 re 2006-03-24T19:10:57 argh. javascript ist so scheiße :-/ 2006-03-24T19:11:03 birkenfeld: wird irgendwann mal python sandboxed sein? 2006-03-24T19:52:19 mitsuhiko: nach den problemen, dies mit restricted execution schon gab, wohl eher nicht 2006-03-24T19:52:59 naja. selbst wenn wirds javascript nicht so schnell ersetzten 2006-03-24T19:53:15 eher gar nicht... 2006-03-24T19:53:55 birkenfeld: aber jetzt bekommt javascript ja eh viele python features 2006-03-24T19:54:07 nur werden das wieder 3% der browser unterstützen :/ 2006-03-24T19:54:16 hoffentlich setzt sichs durch 2006-03-24T19:55:43 * birkenfeld geht mal schnell den X-Server neustarten 2006-03-24T19:56:01 *** birkenfeld has quit IRC 2006-03-24T19:57:07 *** birkenfeld has joined #pocoo 2006-03-24T19:57:17 so 2006-03-24T19:57:20 wb birkenfeld 2006-03-24T19:57:21 blödes RenderAccel 2006-03-24T19:57:28 welcher treiber? 2006-03-24T19:57:38 nvidia 2006-03-24T19:57:43 * mitsuhiko hat hier eine ATI9700 Pro im Notebook und nur scherereien 2006-03-24T19:58:16 ich glaubs dir 2006-03-24T19:58:26 mein notebook hat eine i915 2006-03-24T19:58:36 ohne X 6.9+ hab ich die gar nicht zum laufen gekriegt 2006-03-24T19:59:08 etwas mehr Hardware support von seiten der hersteller wäre wunderbar 2006-03-24T19:59:14 s/Hardware/Linux/ 2006-03-24T20:00:11 .oO( *träum* ) 2006-03-24T20:00:32 da hab ichs wieder: http://weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html 2006-03-24T20:00:56 mitsuhiko: mit windows wäre das nicht passiert 2006-03-24T20:01:18 xorAxAx: stimmt, da hätte ich millionen anderer Probleme. Wie die nervige Lüfung meines Notebooks 2006-03-24T20:01:20 * xorAxAx hat ati 7500 2006-03-24T20:01:30 mitsuhiko: ah, die patcht du bei linux aus? :) 2006-03-24T20:01:39 mitsuhiko: macht das nicht impotent? :) 2006-03-24T20:01:44 xorAxAx: nein, die hab ich hier nicht 2006-03-24T20:01:59 also bei ibm macht das die firmware und nicht windows - das lüften 2006-03-24T20:02:03 mein notebook hat nämlich unter windows einen treiber fehler gehabt 2006-03-24T20:02:10 aso 2006-03-24T20:03:39 ich muss ernsthaft sagen, dass Arbeiten unter windows irgendwie witzlos ist 2006-03-24T20:03:46 IMHO 2006-03-24T20:04:41 mitsuhiko: zurück zum thema: wie sollen wir es denn mit dem caching halten? 2006-03-24T20:05:07 einen verkorksten ansatz gibts unter pocoo.pkg.core.cache 2006-03-24T20:05:10 aber das ist nicht gut 2006-03-24T20:05:11 :) 2006-03-24T20:05:24 man bräuchte zwei caching stufen. eine für disk cache und eine für memory 2006-03-24T20:05:42 im idealfall könnte man optional memcached einbinden 2006-03-24T20:05:43 mitsuhiko: auf den hab ich gerade einen wrapper gesetzt 2006-03-24T20:06:00 mitsuhiko: es geht mir weniger darum, wie wir cachen, sondern was 2006-03-24T20:06:36 gecacht sollten dinge werden, die viel zeit zum erstellen brauchen. ua eben solche sachen wie die templates 2006-03-24T20:07:52 ich hab nämlich den RequestWrapper schön gebaut und danach ist mir aufgefallen dass fertige Seiten eigentlich kaum gecacht werden können 2006-03-24T20:08:38 birkenfeld: caching bei foren ist ja generell ein problem, da die inhalte von user zu user stark variieren und sich schnell ändern 2006-03-24T20:08:46 bei einem wiki ändern sich seiten vielleicht alle 2 Stunden 2006-03-24T20:09:41 eben 2006-03-24T20:10:59 was man auf alle fälle machen kann ist es einen fertigen template context für den anonymen user im speicher zu haben 2006-03-24T20:11:18 dann spart man sich das zusammensammeln der template variablen und co für den 2006-03-24T20:11:43 * mitsuhiko macht sich mal schlau wie andere foren systeme cachen 2006-03-24T20:11:47 *** tabellar has joined #pocoo 2006-03-24T20:13:09 moin tabellar 2006-03-24T20:13:18 hi tabellar 2006-03-24T20:13:26 servus mitanand ... 2006-03-24T20:14:14 birkenfeld: kann man klassen erstellen ohne __init__ aufzurufen? 2006-03-24T20:14:23 dann könnten wir das __cinit__ durch __init__ ersetzen 2006-03-24T20:14:49 mitsuhiko: ich würde mal sagen nein 2006-03-24T20:15:53 birkenfeld: http://pastebin.com/620447 ^^ 2006-03-24T20:16:00 aber ich glaub das ist nicht schön :) 2006-03-24T20:16:25 nö 2006-03-24T20:20:07 birkenfeld: wobei mir jetzt doch eine idee kommt. man könnte die __init__ methode in der metaklasse nach _ClassName__init umbenennen und später genau diese methode aufrufen 2006-03-24T20:20:38 mitsuhiko: wieso eigentlich? 2006-03-24T20:21:16 birkenfeld: weil __cinit__ aktuell genau das gleiche wie __init__ ist, nur dass es halt ein paar ms später aufgerufen wird 2006-03-24T20:21:34 kommt mir so redundant vor 2006-03-24T20:21:56 meinetwegen kann man das schon so machen 2006-03-24T20:23:47 .oO(Immer diese Grundsatzfragen ^^) 2006-03-24T20:24:00 *g* 2006-03-24T20:27:20 hm. schweigen von den phpBB leuten. Ich glaub die haben einfach kein caching 2006-03-24T20:27:28 hehe 2006-03-24T20:27:46 .oO( kein Wunder ) 2006-03-24T20:28:41 jup 2006-03-24T20:31:07 --> http://trac.pocoo.org/wiki/WhatToCache 2006-03-24T20:32:50 haha 2006-03-24T20:33:02 many-to-many relationships scheinen aufs erste zu gehn 2006-03-24T20:33:12 hm, dazu hätte ich vielleicht ein paar Ideen 2006-03-24T20:33:46 ach. nochwas. momentan fägen wir ja pocoo.db.Model nach meta ein. Sollte man das überhaupt machen? Wenn ja warum nicht auch ``one`` und ``many``? :-) 2006-03-24T20:34:09 mitsuhiko: eigentlich ist das ja böse 2006-03-24T20:34:18 jup 2006-03-24T20:34:27 man köntne das module subclassen *ggg* 2006-03-24T20:37:14 wegen caching: ich mach mir zur Zeit Gedanken, ob man pro usersession (view) diverse daten vorhalten soll. Sprich z.B. eine Forums- und Threadliste. Solange kein update des forum und thread models gemacht wird, brauch auch die DB nicht unbedingt abgefragt werden. Gibt es ein update oder neues thread, Forum etc. aktualisiert der Controler (MVC) die userviews ... das ist dann ziemlich schnell ^^ 2006-03-24T20:37:48 ideal für ajax... 2006-03-24T20:38:08 tabellar: in der regel merken sich foren aber welche threads man gelesen hat oder nicht. Sollte pocoo das früher oder später auch brauchen (was es tun wird) wird daraus aber nix :) 2006-03-24T20:38:28 und ajax ist zwar nett, aber es belastet den server auch wieder durch verdammt viele requests 2006-03-24T20:38:34 und braucht einen JS enabled browser 2006-03-24T20:38:50 argh. einen browser mit aktiviertem java skript :) 2006-03-24T20:39:41 ja, ja, Thema barrierefreies designen... 2006-03-24T20:40:03 es kommt immer auf die App an... 2006-03-24T20:40:36 ich glaub ein webforum ist die mit abstand performancelastigste webanwendung 2006-03-24T20:42:48 mir ging es weniger um das merken der gelesenen threads, sondern dass sich das system z.B. typische Listenabfragen (Foren, etc., Threads pro Forum, etc.) merkt. Gibt es keine Änderung am Modell, brauch auch die DB nicht neu selected werden 2006-03-24T20:43:30 tabellar: so wie ich das sehe tut das bereits SQLAlchemy. mitsuhiko? 2006-03-24T20:43:49 birkenfeld: caching von rows? weiß nicht 2006-03-24T20:44:06 mitsuhiko: caching von objects 2006-03-24T20:44:36 zumindest kommt sqlalchemy in load balanced environments (wie sagt man da auf deutsch) zurecht 2006-03-24T20:45:00 belastungsausgleichende umgebungen ;) 2006-03-24T20:45:13 genau :) 2006-03-24T20:46:06 z.B. python-forum.de hatte bisher max. 39 user gleichzeitig. Das sind nicht besonders viele. Die zu speichernden userviews sind da nicht riesig... 2006-03-24T20:46:27 tabellar: pocoo soll mal auf ubuntuusers.de laufen und da gibts aber zugriffe en masse 2006-03-24T20:46:40 zwar auch noch verhältnismäßig wenig, aber genug 2006-03-24T20:47:23 aber wie gesagt. zumindest den anonymen user könnte man wunderbar cachen 2006-03-24T20:48:08 wobei spätestens, wenn jede minute ein post kommt kann man das caching kicken, da es aufwendiger als das auswählen aus der db ist 2006-03-24T20:48:14 war nur ein Bsp. ... aber ich denke es ist trotzdem erstrebenswert, Daten, die z.B. schon mal von der DB geholt worden sind, zu speichern pro session. Erst wenn sich das Modell ändert (DB), müssen per Controler die userviews upgedated werden 2006-03-24T20:50:42 updates können ja im Hintergrund laufen, sind ja keine real multi views... 2006-03-24T20:52:31 cool 2006-03-24T20:52:36 es geht 2006-03-24T20:52:43 fehler werfen mal anders :) 2006-03-24T20:52:48 javascript ist so grausig *brzzz* 2006-03-24T20:52:49 was denn= 2006-03-24T20:53:07 birkenfeld: ich hab eine funktion raise gemacht, die fehler loggt und mit throw weiterwirft :) 2006-03-24T20:53:16 solange man nur raise verwendet gibts output im logger 2006-03-24T20:54:06 :) 2006-03-24T21:00:16 mir fällt gerade ein, dass wir noch kein system für die links haben. sollen die templates "hart gekodete" (rofl?) links verwenden, oder haben wir das was besseres? 2006-03-24T21:12:18 mitsuhiko: wir brauchen ja dann noch einen URL rewriter, der die session ID an alle Links anhängt 2006-03-24T21:13:20 ich werd mich mal schlau machen wie man erkennt ob das setzten eines cookies hinhaut 2006-03-24T21:13:24 mitsuhiko: ^^^^^^^^^^^^^^^^^^^^^ this is a joke 2006-03-24T21:13:39 entweder cookies oder HTTP Auth 2006-03-24T21:13:49 stimmt. http auth wäre eine möglichkeit 2006-03-24T21:19:44 Warum das session handling nicht direkt in der DB machen? Hätte auch Vorteile bei RPC Zugriffen... 2006-03-24T21:20:04 tabellar: wie meinst du das? 2006-03-24T21:22:08 tabellar: mit dynamischen views? 2006-03-24T21:22:11 wir(ich) haben die Session und Accessverwaltung immer zentral in der DB. Sprich der User kommt immer von aussen mit der ihm zugeteilten session id, egal ob per http oder rpcs...b per 2006-03-24T21:22:37 dyn. views? 2006-03-24T21:22:49 + session id? 2006-03-24T21:23:24 session id und dyn. views geht beides... 2006-03-24T21:24:58 jeder dyn. view pro session id wird im viewmanager registriert... 2006-03-24T21:25:14 oder auch nur ein dict ;-) 2006-03-24T21:25:38 tabellar: wie sessions liegen in der db, wenn du das meinst 2006-03-24T21:25:51 ? 2006-03-24T21:26:51 user fordert seite an, meldet sich an, bekommt cookie mit session id zugestellt, fordert seite neu an, übermittelt session id zum server, server holt sich die session daten aus der datenbank 2006-03-24T21:28:26 hm, wir arbeiten ohne cookies... 2006-03-24T21:28:44 tabellar: und die session id wird wie übermittelt? url? 2006-03-24T21:30:25 ja, url ... get oder post ... oder via beliebiges IM Protokoll (z.B. JSON ) ... im json dict z.B. {'sid': sasd12312, ... } 2006-03-24T21:30:54 birkenfeld: mach schon mal den rewriter warm :) 2006-03-24T21:32:01 link?sid=%{sid}s :) 2006-03-24T21:32:24 sids in der url sind nicht ganz ungefährlich 2006-03-24T21:33:08 deshalb versuche ich sie auch zu vermeiden -> POST -> AJAX mit getElementById('sid') ... 2006-03-24T21:34:31 ich will keine Links mit sid=... , aber die URL im Browser leidet dann. Konsequenterweise darf man auf die URL im Browser keinen grossen Wert legen ... URLScheme etc. 2006-03-24T21:35:35 user mit deaktivierten cookies sind ja gott sei dank die ausnahme, aber derwegen müsste man das irgendwie hinbekommen. Http Auth ist eine möglichkeit, aber da muss der Webserver mitspielen 2006-03-24T21:36:06 http auth wäre aber dann auch für jsonrpc/xmlrpc brauchbar 2006-03-24T21:36:16 xorAxAx: bei moin gibts nur den weg mit dem cookie oder? 2006-03-24T21:36:37 mitsuhiko: moin hat ein pluggable auth aber kein session system 2006-03-24T21:37:03 hm. stimmt 2006-03-24T21:37:10 mit dem durfte sich beewee rumärgern :) 2006-03-24T21:37:53 ich mag die cookies nicht ... wenn ich mir vorstellen, ein anderer könnte an meiner Stelle im Browser rumspielen... nicht sicher genug... 2006-03-24T21:37:57 mitsuhiko: in 1.3 hatte es noch keins 2006-03-24T21:38:14 tabellar: was ist an cookies so unsicher? 2006-03-24T21:38:15 tabellar: jo, dann bau mal das sessionsystem 2006-03-24T21:38:46 ist doch nicht schwierig, da könnt ihr schon ganz andere Dinge :) 2006-03-24T21:39:27 die größten features in moin 1.5 wurden oft gegen geld entwickelt 2006-03-24T21:39:59 ich überleg mir ja atm ob wir eine moin parser bridge einbauen 2006-03-24T21:41:14 mitsuhiko: moin parser müssen einen formatter aufrufen 2006-03-24T21:41:25 mitsuhiko: du musst also auch einen formatter bereitstellen 2006-03-24T21:45:28 jo 2006-03-24T21:49:38 kennt ihr die Seite? http://jsolait.net/wiki/examples/jsonrpc/canvas ... wäre vielleicht was für den Idea pool... chat, draw... 2006-03-24T21:49:49 aber der wiki.py braucht z.b. ziemlich viel Page.py code etc. 2006-03-24T21:49:56 tabellar: kenn ich 2006-03-24T21:50:04 :) 2006-03-24T21:50:05 xorAxAx: es ginge eher darum, dass pocoo und moin ein ähnliches parser interface hat 2006-03-24T21:50:10 s/hat/haben/ 2006-03-24T21:50:37 mitsuhiko: dafür müsstest du die halbe moin api emulieren :) 2006-03-24T21:50:49 damit man moin parser nutzen kann 2006-03-24T21:52:11 xorAxAx: da hättest du eine canvas anwendung :) 2006-03-24T21:52:14 *** birkenfeld has quit IRC 2006-03-24T21:52:22 mitsuhiko: wo? 2006-03-24T21:52:28 *** birkenfeld has joined #pocoo 2006-03-24T21:52:48 xorAxAx: http://jsolait.net/wiki/examples/jsonrpc/canvas 2006-03-24T21:52:51 wb birkenfeld 2006-03-24T21:55:02 xorAxAx: laut text funzt das mit IE6+adobe svg viewer auch 2006-03-24T21:55:31 mitsuhiko: ie kann canvas? 2006-03-24T21:55:48 xorAxAx: mit adove svg viewer anscheinend 2006-03-24T21:56:29 wär doch was neues in einem Forum, oddrrr??? 2006-03-24T21:56:41 klar :) 2006-03-24T21:56:42 chatroom..., drawingroom, ... 2006-03-24T21:56:48 in opera gehts nicht 2006-03-24T21:56:55 ich kritzele gerade mit IE7 perl durch 2006-03-24T21:57:03 die dürfen halt nicht mitspielen... 2006-03-24T21:57:35 gibts kein SVG-Plugin für opera? 2006-03-24T21:58:06 birkenfeld: afaik kann der das out of the box 2006-03-24T21:58:25 mitsuhiko: diese anwendung läuft nicht :) 2006-03-24T21:58:34 mitsuhiko: und von steht da nix 2006-03-24T21:58:57 im Konqueror kann ich zwar zeichnen, aber er synchronisiert nicht 2006-03-24T21:59:07 ich brauche auch kein canvas, wenn svg hinreichend weit verbreitet wäre 2006-03-24T21:59:16 birkenfeld: konqueror kann canvas? 2006-03-24T21:59:18 das ist aber neu 2006-03-24T21:59:27 mitsuhiko: das ist nicht mit canvas 2006-03-24T21:59:29 *sigh* 2006-03-24T22:00:51 hm, da freuen sich leute mit grafiktablett 2006-03-24T22:00:53 das ist rofl: http://jsolait.net/examples/draw/draw.svg 2006-03-24T22:01:04 ein svg mit javascript drin 2006-03-24T22:01:41 pocoo design im internet ... ;-) 2006-03-24T22:01:55 mitsuhiko: ALT 2006-03-24T22:01:57 xorAxAx: ich wusste nicht, dass man svgs mit javascript verändern kann 2006-03-24T22:02:02 mitsuhiko: such mal nach pacman 2006-03-24T22:02:18 xorAxAx: oder tetris 2006-03-24T22:02:25 aber json dabei ist mir komplett neu 2006-03-24T22:03:00 alles divs... extrem... 2006-03-24T22:05:23 wie kann man tippen? 2006-03-24T22:05:30 xorAxAx: auf dem feld da unten 2006-03-24T22:05:37 untern bei text message :) 2006-03-24T22:05:53 ah 2006-03-24T22:06:27 scharf, oddrrr? 2006-03-24T22:07:32 ROFL ROFL ROFL 2006-03-24T22:08:44 wie's da wohl mit der Haftung ausschaut? 2006-03-24T22:09:00 birkenfeld: wie bei einem wiki 2006-03-24T22:09:08 oder dem heise forum 2006-03-24T22:09:34 d.h. der admin ist lt. eines urteils schuld 2006-03-24T22:09:36 (vgl. heise) 2006-03-24T22:09:39 in .de 2006-03-24T22:09:47 stimmt 2006-03-24T22:11:37 aber ansonsten ist er erst schuld, wenn ers weiß und nix macht 2006-03-24T22:11:57 da fehlt ein radiergummi 2006-03-24T22:16:17 ROFL ROFL ROFL 2006-03-24T22:16:21 Ein Feature von PHP zur Erhöhung der Sicherheit ist die Konfiguration von PHP mit register_globals = off. 2006-03-24T22:16:32 "Ein Feature zur Erhöhung der SIcherheit" 2006-03-24T22:16:43 das man für sowas auch noch werbung machen muss 2006-03-24T22:17:13 und dann kommen die leute und beschweren sich dass auf ihrem webspace register_globals aus is 2006-03-24T22:18:19 birkenfeld: kann man sich aber selber nachbauen 2006-03-24T22:18:42 mitsuhiko: auch in python... ;) 2006-03-24T22:18:47 extract($_COOKIES); extract($_REQUEST) :-) 2006-03-24T22:18:51 birkenfeld: pssst :) 2006-03-24T22:19:06 HE, LEUTE! 2006-03-24T22:19:12 ICH WEISS WAS... 2006-03-24T22:19:29 *grmpf* 2006-03-24T22:19:34 n8 :) 2006-03-24T22:19:38 lol? 2006-03-24T22:19:44 *** birkenfeld has quit IRC 2006-03-24T23:03:35 wie kann ich denn ein JavaScript Dict (hashtable) in einen String wandeln? toString({}) funzt net... 2006-03-24T23:03:57 tabellar: http://trac.pocoo.org/repos/pocoo/trunk/pocoo/lib/json.js 2006-03-24T23:05:28 tabellar: json.toJSON({}) tuts 2006-03-24T23:06:37 so aufwendig? kein str({}) oder ähnliches??? ... ts,ts, ts... 2006-03-24T23:06:49 nö. warum auch 2006-03-24T23:07:06 du suchst ja nicht str() sondern repr() 2006-03-24T23:07:23 ich hö 2006-03-24T23:07:59 ich hätte eigentlich gern das pendant zu python ... dict={} -> str(dict) ... 2006-03-24T23:08:14 tabellar: das hab ich dir ja gepostet 2006-03-24T23:08:29 und wie gesagt. du suchst nicht str(dict) sondern repr(dict) 2006-03-24T23:08:36 im falle von dict isses halt zufälligerweise das gleiche 2006-03-24T23:08:57 ok, passt 2006-03-24T23:29:24 toJSON funzt, danke :) 2006-03-24T23:50:44 so, ab in's Bett 2006-03-24T23:51:43 *** tabellar has quit IRC