Ich beobachte schon Tine 2.0 seit ich davon zum ersten mal gehört habe, vor allem weil es mich interessiert was die Leute aus ExtJS herausholen können (wobei ich eher zu Qooxdoo neige ).
Allerdings erscheint mir die Wahl nativer Browserfenster als nicht wirklich gelungen. Die Startzeit ist, auch dank Fat-JS Lib, doch eher hoch. Bei mir sind es gestoppt 4 Sekunden bis das Popup benutzbar wurde (einmal waren es sogar 12 Sekunden).
Ich muss ehrlich sagen das ich zwar die Geschwindigkeit der Main-GUI gut finde, aber die Popups als zentrales Element mir zu langsam sind.
Da ich selbst gerne Fat-JS libs nutze und auch selbst schon vor dieser entscheidung stand würde es mich interessieren wie es der Rest hier so sieht.
Was ist wichtiger:
1. Native Fenster, auch wenn sie langsamer laden 2. JS-Inline Fenster (also im Browserclient) die dafür schnell laden.
Wobei auch nicht ganz unerwähnt bleiben sollte das jedes neue Browserfenster mit einer Fat-Lib natürlich auch weiteren Arbeitsspeicher frisst und Rechenzeit verbraucht. Aber wie stark das durchschlägt kann ich offen gesagt nicht genau deuten.
Ich meinte damit eine große und komplexe JS Lib die viel Speicher und Bandbreite frist. Beispiele hierfür sind ExtJS, Qooxdoo und andere. die jeweils "kompiliert" und komprimiert schnell über 500 KB groß sind.
Von Lars Kneschke (Tine 2.0 Core E am Sa, 19. Juli 2008 um 16:39 #
Die Native Fenster werden noch schneller. Das ist nur eine temporäre Einschränkung. Wir können den Code so umstellen das für ein natives Fenster kein Request zum Webserver mehr nötig ist. Ist nur Arbeit die wir momentan erst einmal nicht machen wollen, da wir das sehr intensiv testen müssen.
Davon unabhängig stellst Du ja eigentlich die Frage nach MDI Applikationen(http://en.wikipedia.org/wiki/Multiple_document_interface). Die Pro und Cons findest Du alle in den Wikipedia Artikel.
Was ich bei all dem Ajax nicht verstehe: Wies baut man Desktopapplikationen en Detail im Browser nach, statt vorhandene Desktopapplikationen über Netzwerke zu verwenden? Ist 'ne ernstgemeinte ketzerische Frage.
Bevor jetzt jemand sagt: "Jaaa X11 über Internet macht keinen Spaß", der hat noch nie was von NX gehört. NX erzeugt extrem wenig Netzwerktraffic bei gleichzeitig flüssiger Bedienung (NX zu schlagen dürfte für Webapps unmöglich sein).
Obendrein gib es NX-Clients für jedes Betriebssystem, also auch Windows und lässt sich sogar aus dem Browser heraus starten (das Flashplugin ist da deutlich nerviger ;-).
An Ajaxapps nervt, dass sie in wirklich in jedem Browser dieser Erde anders sind und einen Heidenaufwand bedeuten, wenn man wirklich auf jeder Plattform sein will (ich weiß Browser wie "Konqueror" sind kein Markt und somit Schuld des Kunden). NX baut auf überall gleichen Standards auf: X11 & OpenSSH.
Das "Killerargument", dass man bei Ajaxanwendungen nix mehr installieren müsse, weil schon alles da ist zieht auch nicht. Man ist auf Gedeih und Verderb auf eine bestimmte aktuelle Version eines oder einiger weniger Browser angewiesen welche oft genug genau dann wenn man sie braucht, nicht zur Verfügung stehen und erst installiert werden müssen.
Von Lars Kneschke (Tine 2.0 Core E am So, 20. Juli 2008 um 06:54 #
Dagegen sprechen mehrere Argumente.
1.) Anzahl der installierten Browser(Firefox>2.0 + IE>6 + Safari>? + Opera>?) im Verhältnis zu installierten NX Clients. Da dürfte also bestimmt so etwas wie 100000 : 1 rauskommen. Ein aktueller Browser ist heute für jedes aktuelle Betriebssystem verfügbar und per default installiert. Auf einem Rechner wo man nicht einen der oben genannten Browser findet, wird man sehr wahrscheinlich auch NX nicht zu fliegen kriegen.
2.) Ein PHP Request belegt für 1 Sekunde vielleicht 32MByte RAM. Wenn man davon ausgeht das man im NX einen Desktop(z.B. KDE) anbieten müsste, sind das bestimmt ~300 MByte. Wahrscheinlich eher mehr. Die 300 MByte belegt der User auch, wenn er nichts tut aber trotzdem angemeldet bleibt. Bei einem Server mit 3GByte Ram würde das bedeuten das sich maximal 9 Leute gleichzeitig anmelden können. Das ist die Webapplikation deutlich skalierbarer.
3.) Die GUI wird auf dem Client erzeugt. Bei NX läuft die ganze Logik und die Darstellung auf dem Server. Dir geht also nicht nur sehr schnell das RAM aus, sondern auch die verfügbare CPU Leistung.
4.) Tine 2.0 sieht auf jedem Browser gleich aus und ist kein Heidenaufwand. Dafür sorgt ExtJS als Framework. Damit haben wir als Applikationsentwickler nix zu tun.
Übrigens ist Tine 2.0 keine AJAX Applikation. Wir tauschen JSON aus und kein XML. Also eher AJAJ.
zu 1 und 4) Sicher installierte NX-Clients gibt es weniger, deswegen ja auch ein Hinweis, dass sich das Ganze relativ bequem auch aus dem Browser heraus laden lässt (so in etwas wie ein Plugin).
Leider heißt aktueller Browser derzeit viel zu oft "Firefox". Früher hieß er "Internet Explorer" und alle Welt hat sich damals aufgeregt. Die gleichen Leute, die sich damals aufgeregt haben, haben jetzt aber kein Problem mehr mich als Exot abzustempeln, wenn ich sage, dass der Browser meiner Wahl Konqueror heißt. Vor allem komplexe Webapplikationen sind häufig so gestrickt, dass man entweder den User Agent faken muss (z.B. bei Googlediensten klappt danach auf einmal alles wunderbar) oder Bugs anderer Browser nachimplementieren muss (z.B. vergessene Semikolons in Javascript erzeugen in bestimmten Fällen auf Firefox keinen Fehler). Was ich damit sagen will ist dass Web eine ungeheuer komplexe Umgebung ist, viel komplexer als andere, die für gewisse Anwendungsfälle (netzwerkfähige Anwendungen) zum selben Ergebnis mit erheblich reduzierter Komplexität führen.
zu 2 und 3) NX muss man nicht im Desktopmodus betreiben. Man kann auch einzelne Applikationen über NX starten. Freilich muss man dann immer noch eine Reihe Bibliotheken im RAM vorhalten, aber es reduziert doch etwas die Last sowohl beim Server als auch beim Client. Bei ~300MB pro Client hätte ich nie eine Chance gehabt mit meinem alten Duron 700 mit 256 MB RAM ohne Swap zu nutzen meinen Desktop per NX zu exportieren. 150MB sollte für vergleichbare Dinge (Groupware, einfache Officeprogramme) ein komfortabler Wert sein. Dennoch stimme ich dir zu, dass eine Webapplikation Vorteile auf Serverseite bietet. Übertragene Datenmenge und Rechenzeit auf Clientseite sehen bei NX aber günstiger aus.
P.S.: Das mit Ajax war auch mehr als Metapher für das Phänomen der Programme im Browser gemeint.
Im Grunde hast du zwar schon eine Antwort erhalten, aber ich wills einfach auch beantworten ;)
Die von dir vorgeschlagene Lösung NX ist zwar wie schon geschrieben wurde, ganz nett, verbraucht auf Serverseite aber sehr viel Last. Es muss durchgehend eine Anwendung dort offen bleiben, auch wenn du gerade etwas anderes tust. Das auch eigentlich niemand auf dieser Welt einen NX Client hat brauche ich wohl nicht zu erwähnen ;)
Wesentlicher aber ist das auch mit NX die Geschwindigkeit einer solchen Anwendung ganz wesentlich schlechter ist als mit einer sauber entwickelten Ajaxanwendung. Das kann ich dir garantieren da ich starker Nutzer von beidem bin.
Auch ist die Frage nach der Gleichheit eigentlich keine. Es gibt im Markt mehrere große Libs die sich zum Ziel gesetzt haben die Entwicklung für alle Browser zu vereinheitlichen, und in jedem Browser die Anwendungen performant darzustellen.
Beispiele dafür sind: - Qooxdoo - ExtJS
(Etwas weniger Umfangreich bzw. andere Ziele:) - Yahoo! UI Library - Dojo Toolkit
Selbst wenn jemand z.B. nur einen IE 5 hat (schwieriger Browser) könnte man anstatt zu sagen "hol dir NX" ihnen auch sagen "hol dir den Firefox". Dann haben sie wenigstens auch gleich einen modernen Browser.
Übrigens läuft Qooxdoo mit jedem IE ab IE 5.5, den aktuellem Safari (die vorherigen waren nicht geeignet da sie Bugs enthielten), Opera ab V. 8, und Gecko Browser ab 1.7 [also Firefox 1.0]. Ich habe die Qooxdoo Apps auch schon auf meinem N800 mit dessen kleinem Gecko Browser getestet, es lief.
Und nicht zu vergessen zu guter letzt: Es ist ein guter Entwicklungsstil Darstellungslogik und Backend zu trennen und nur die benötigten Daten zu übertragen. Das macht heute sowieso jede kleine Anwendung, und funktioniert gut. Das erlaubt aufwendige Renderaufgaben auf die meist wenig ausgelasteten Clients zu verlagern und die Server optimaler zu nutzen. Eine JS-Clientanwendung ist hier ein guter Schritt für, zumal sie dank JS auch heute durchaus "schick" entwickelt werden können.
Was mich übrigens eher überrascht ist das du NX als Alternative nennst, was ich für wirklich weit hergeholt halte, aber nicht Java. Das wäre viel naheliegender, und ist heute natürlich bereits so im Einsatz wie es JS Apps auch sind. Und dank Webapps geht es dort auch sehr einfach.
Mein Einwand war als Reflektion gedacht, wieviel von dem was sich derzeit im Browseranwendungsmarkt tummelt funktionell und technisch Sinn macht (wirtschaftlich tut es das wohl irgendwie, da viele Firmen damit ihr Geld verdienen) und ob man da nicht das Rad wieder unnötig neu erfindet.
Von daher ist auch mein Vergleich mit NX statt Javaapplets nicht so weit her geholt. Es ging mir nicht darum quantitativ vergleichbar im Markt vorhandene Alternativen zu nennen, sondern zu fragen warum eine Lösung die bedeutend weniger teure Entwicklerressourcen benötigt (keine neuen Anwendungen müssen entwickelt werden im Gegensatz zum Web) kaum in Erwägung gezogen wird.
Schön zu hören das ihr daran arbeitet. Ich kenne die Möglichkeiten zu externen Fenstern nicht sonderlich gut. Aber wenn ihr es schafft das externe Fenster mit der Haupt-JS zu befüllen habt ihr die Geschwindigkeitsprobleme vermutlich gelöst.
Aber eigentlich geht meine Frage eher nicht in die MDI/SDI Richtung, mir geht es einzig und allein um die Geschwindigkeit. Ansonsten würde ich externe Fenster selbst vorziehen, vor allem aber da sie besser zum Systen passen. Die Frage von mir war eben eher ob der Geschwindigkeitsnachteil für viele Relevant wäre.
Aktuell erhalte ich nur eine Fehlermeldung wenn sich die Listen öffnen sollen:
/m3/www/sites/officespot/ demo.egroupware20.org/htdocs/Tinebase/Controller.php(183): Zend_Json_Server->handle([object Object])
/m3/www/sites/officespot/ demo.egroupware20.org/htdocs/index.php(29): Tinebase_Controller->handle()
Wie schauts bei euch aus?
Allerdings erscheint mir die Wahl nativer Browserfenster als nicht wirklich gelungen. Die Startzeit ist, auch dank Fat-JS Lib, doch eher hoch. Bei mir sind es gestoppt 4 Sekunden bis das Popup benutzbar wurde (einmal waren es sogar 12 Sekunden).
Ich muss ehrlich sagen das ich zwar die Geschwindigkeit der Main-GUI gut finde, aber die Popups als zentrales Element mir zu langsam sind.
Da ich selbst gerne Fat-JS libs nutze und auch selbst schon vor dieser entscheidung stand würde es mich interessieren wie es der Rest hier so sieht.
Was ist wichtiger:
1. Native Fenster, auch wenn sie langsamer laden
2. JS-Inline Fenster (also im Browserclient) die dafür schnell laden.
Wobei auch nicht ganz unerwähnt bleiben sollte das jedes neue Browserfenster mit einer Fat-Lib natürlich auch weiteren Arbeitsspeicher frisst und Rechenzeit verbraucht. Aber wie stark das durchschlägt kann ich offen gesagt nicht genau deuten.
Beispiele hierfür sind ExtJS, Qooxdoo und andere. die jeweils "kompiliert" und komprimiert schnell über 500 KB groß sind.
Davon unabhängig stellst Du ja eigentlich die Frage nach MDI Applikationen(http://en.wikipedia.org/wiki/Multiple_document_interface). Die Pro und Cons findest Du alle in den Wikipedia Artikel.
Bevor jetzt jemand sagt: "Jaaa X11 über Internet macht keinen Spaß", der hat noch nie was von NX gehört. NX erzeugt extrem wenig Netzwerktraffic bei gleichzeitig flüssiger Bedienung (NX zu schlagen dürfte für Webapps unmöglich sein).
Obendrein gib es NX-Clients für jedes Betriebssystem, also auch Windows und lässt sich sogar aus dem Browser heraus starten (das Flashplugin ist da deutlich nerviger ;-).
An Ajaxapps nervt, dass sie in wirklich in jedem Browser dieser Erde anders sind und einen Heidenaufwand bedeuten, wenn man wirklich auf jeder Plattform sein will (ich weiß Browser wie "Konqueror" sind kein Markt und somit Schuld des Kunden). NX baut auf überall gleichen Standards auf: X11 & OpenSSH.
Das "Killerargument", dass man bei Ajaxanwendungen nix mehr installieren müsse, weil schon alles da ist zieht auch nicht. Man ist auf Gedeih und Verderb auf eine bestimmte aktuelle Version eines oder einiger weniger Browser angewiesen welche oft genug genau dann wenn man sie braucht, nicht zur Verfügung stehen und erst installiert werden müssen.
1.) Anzahl der installierten Browser(Firefox>2.0 + IE>6 + Safari>? + Opera>?) im Verhältnis zu installierten NX Clients. Da dürfte also bestimmt so etwas wie 100000 : 1 rauskommen. Ein aktueller Browser ist heute für jedes aktuelle Betriebssystem verfügbar und per default installiert. Auf einem Rechner wo man nicht einen der oben genannten Browser findet, wird man sehr wahrscheinlich auch NX nicht zu fliegen kriegen.
2.) Ein PHP Request belegt für 1 Sekunde vielleicht 32MByte RAM. Wenn man davon ausgeht das man im NX einen Desktop(z.B. KDE) anbieten müsste, sind das bestimmt ~300 MByte. Wahrscheinlich eher mehr. Die 300 MByte belegt der User auch, wenn er nichts tut aber trotzdem angemeldet bleibt. Bei einem Server mit 3GByte Ram würde das bedeuten das sich maximal 9 Leute gleichzeitig anmelden können. Das ist die Webapplikation deutlich skalierbarer.
3.) Die GUI wird auf dem Client erzeugt. Bei NX läuft die ganze Logik und die Darstellung auf dem Server. Dir geht also nicht nur sehr schnell das RAM aus, sondern auch die verfügbare CPU Leistung.
4.) Tine 2.0 sieht auf jedem Browser gleich aus und ist kein Heidenaufwand. Dafür sorgt ExtJS als Framework. Damit haben wir als Applikationsentwickler nix zu tun.
Übrigens ist Tine 2.0 keine AJAX Applikation. Wir tauschen JSON aus und kein XML. Also eher AJAJ.
zu 1 und 4)
Sicher installierte NX-Clients gibt es weniger, deswegen ja auch ein Hinweis, dass sich das Ganze relativ bequem auch aus dem Browser heraus laden lässt (so in etwas wie ein Plugin).
Leider heißt aktueller Browser derzeit viel zu oft "Firefox". Früher hieß er "Internet Explorer" und alle Welt hat sich damals aufgeregt. Die gleichen Leute, die sich damals aufgeregt haben, haben jetzt aber kein Problem mehr mich als Exot abzustempeln, wenn ich sage, dass der Browser meiner Wahl Konqueror heißt. Vor allem komplexe Webapplikationen sind häufig so gestrickt, dass man entweder den User Agent faken muss (z.B. bei Googlediensten klappt danach auf einmal alles wunderbar) oder Bugs anderer Browser nachimplementieren muss (z.B. vergessene Semikolons in Javascript erzeugen in bestimmten Fällen auf Firefox keinen Fehler). Was ich damit sagen will ist dass Web eine ungeheuer komplexe Umgebung ist, viel komplexer als andere, die für gewisse Anwendungsfälle (netzwerkfähige Anwendungen) zum selben Ergebnis mit erheblich reduzierter Komplexität führen.
zu 2 und 3) NX muss man nicht im Desktopmodus betreiben. Man kann auch einzelne Applikationen über NX starten. Freilich muss man dann immer noch eine Reihe Bibliotheken im RAM vorhalten, aber es reduziert doch etwas die Last sowohl beim Server als auch beim Client. Bei ~300MB pro Client hätte ich nie eine Chance gehabt mit meinem alten Duron 700 mit 256 MB RAM ohne Swap zu nutzen meinen Desktop per NX zu exportieren. 150MB sollte für vergleichbare Dinge (Groupware, einfache Officeprogramme) ein komfortabler Wert sein. Dennoch stimme ich dir zu, dass eine Webapplikation Vorteile auf Serverseite bietet. Übertragene Datenmenge und Rechenzeit auf Clientseite sehen bei NX aber günstiger aus.
P.S.: Das mit Ajax war auch mehr als Metapher für das Phänomen der Programme im Browser gemeint.
Die von dir vorgeschlagene Lösung NX ist zwar wie schon geschrieben wurde, ganz nett, verbraucht auf Serverseite aber sehr viel Last. Es muss durchgehend eine Anwendung dort offen bleiben, auch wenn du gerade etwas anderes tust.
Das auch eigentlich niemand auf dieser Welt einen NX Client hat brauche ich wohl nicht zu erwähnen ;)
Wesentlicher aber ist das auch mit NX die Geschwindigkeit einer solchen Anwendung ganz wesentlich schlechter ist als mit einer sauber entwickelten Ajaxanwendung. Das kann ich dir garantieren da ich starker Nutzer von beidem bin.
Auch ist die Frage nach der Gleichheit eigentlich keine. Es gibt im Markt mehrere große Libs die sich zum Ziel gesetzt haben die Entwicklung für alle Browser zu vereinheitlichen, und in jedem Browser die Anwendungen performant darzustellen.
Beispiele dafür sind:
- Qooxdoo
- ExtJS
(Etwas weniger Umfangreich bzw. andere Ziele:)
- Yahoo! UI Library
- Dojo Toolkit
Selbst wenn jemand z.B. nur einen IE 5 hat (schwieriger Browser) könnte man anstatt zu sagen "hol dir NX" ihnen auch sagen "hol dir den Firefox". Dann haben sie wenigstens auch gleich einen modernen Browser.
Übrigens läuft Qooxdoo mit jedem IE ab IE 5.5, den aktuellem Safari (die vorherigen waren nicht geeignet da sie Bugs enthielten), Opera ab V. 8, und Gecko Browser ab 1.7 [also Firefox 1.0].
Ich habe die Qooxdoo Apps auch schon auf meinem N800 mit dessen kleinem Gecko Browser getestet, es lief.
Und nicht zu vergessen zu guter letzt: Es ist ein guter Entwicklungsstil Darstellungslogik und Backend zu trennen und nur die benötigten Daten zu übertragen. Das macht heute sowieso jede kleine Anwendung, und funktioniert gut. Das erlaubt aufwendige Renderaufgaben auf die meist wenig ausgelasteten Clients zu verlagern und die Server optimaler zu nutzen. Eine JS-Clientanwendung ist hier ein guter Schritt für, zumal sie dank JS auch heute durchaus "schick" entwickelt werden können.
Was mich übrigens eher überrascht ist das du NX als Alternative nennst, was ich für wirklich weit hergeholt halte, aber nicht Java. Das wäre viel naheliegender, und ist heute natürlich bereits so im Einsatz wie es JS Apps auch sind. Und dank Webapps geht es dort auch sehr einfach.
Von daher ist auch mein Vergleich mit NX statt Javaapplets nicht so weit her geholt. Es ging mir nicht darum quantitativ vergleichbar im Markt vorhandene Alternativen zu nennen, sondern zu fragen warum eine Lösung die bedeutend weniger teure Entwicklerressourcen benötigt (keine neuen Anwendungen müssen entwickelt werden im Gegensatz zum Web) kaum in Erwägung gezogen wird.
Aber eigentlich geht meine Frage eher nicht in die MDI/SDI Richtung, mir geht es einzig und allein um die Geschwindigkeit. Ansonsten würde ich externe Fenster selbst vorziehen, vor allem aber da sie besser zum Systen passen.
Die Frage von mir war eben eher ob der Geschwindigkeitsnachteil für viele Relevant wäre.
Aber die wenigen Antworten zeigen wohl eher: neee
wenn man die URL aufruft befindet sich auf der Seite diese rotierenden Elemente(Auswahl), wie bekommt man dieses programmtechnisch hin?
ruediger
http://194.95.111.244/~countzero/scripts/_myImageFlow/
Viel Spass damit !