Continuations in Webanwendungen (splitt aus dem 3DC-Forum)

[HellHorse]

Wie ist das eigentlich, gibt es irgendwelche Pläne für continuations in ASP.NET?

[HellHorse]

Ich gebe allerdings zu, daß meine imaginäre Webapplikation nicht so simpel aussehen würde, wie ein Bestellsystem im Sinne eines Shops. Es ging mir um unternehmensweite Software mit komplexer Geschäftslogik und ggf. vielen Benutzerinteraktionen.
Du willst continuations, gib's zu ;)

[Crushinator]

Wäre natürlich auch äußerst interessant, aber eigentlich möchte ich mehr so etwas wie alle möglichen Events (z.B. Drag & Drop oder Mousemoves) abfangen können, möglichst viele Informationen (auch Laufbalken/Diagramme) auf einmal darstellen und sie in nahezu Echtzeit anzeigen/aktualisieren können. Dafür taugen Webapplikationen generell nur bedingt, was aber nicht heißt, daß ich sie generell verteufeln möchte. Denn wie heißt das so schön: Right thing for the right job.

[HellHorse]

Ich kann nur zustimmen.

[grakaman]

Was verstehst du unter continuations? Nachdem ich dieses Buzzword nachgeschlagen habe, steht dort nur, dass der Status einer Verarbeitung eingefroren wird und zu einem beliebigen Zeitpunkt später fortgefahren werden kann.

[grakaman]

Nachdem ich mir das Bsp. von Continuations in Coocoon angesehen habe, halte ich das ganze für eine äußerst schlechte Vorgehensweise, vor allem in Bezug auf skalierbare, mission critical Applikationen. Dagegen spricht die sinnlose Ressourcenauslastung und vor allem kann die Applikation nicht mehr skalieren. Um dieses angesprochene Problem der verzögerten Verarbeitung zu umgehen, gibt es viel bessere Möglichkeiten, z.B. eine persistente Speicherung der Session in einer DB oder State Server. Vielleicht reicht sogar auch schon der ViewState aus, wenn die Verarbeitung nur über mehrere Roundtrips einer einzelnen Seite erfolgen soll. Naja, und was den psuedo Workflow a la prozedural angeht, da ist jedes simple DB gesteuerte Workflow System tausend mal besser geeignet. Wozu gibt es denn bitte schön sonst HTTP Handler.

[Crushinator]

Häää? Es spricht seitens Cocoon (http://cocoon.apache.org/2.1/userdocs/flow/how-does-it-work.html) doch nichts gegen die Speicherung in Datenbanken:
(...) Since continuations are objects, you can also store them in a database, for really long-lived session, just like you do with session beans.
Praktische Umsetzung (http://schematics.sourceforge.net/scheme-uk/nmk-case-study.pdf): (Seite 3)
Scheme continuations get stored in the user session of the J2EE application server. Persistence is accomplished by simply storing the serialised continuations in a database; many application servers deal with session migration by serialising the sessions and restoring them on the migration target. This means SISC web applications can be made resilient and load-balanced by simply configuring the appropriate session persistence/migration features of the application server. We have run experiments with Tomcat involving restarting of the application server in the middle of a workfow, and it all works beautifully.
Irgendwie ist dieses Thema überhaupt nicht mehr on Topic. Wäre es zuviel verlangt, an dieser Stelle aufzuhören und die Diskussion falls gewünscht im Programmier- bzw. Technologieforum weiterzuführen?

[grakaman]

Häää? Es spricht seitens Cocoon (http://cocoon.apache.org/2.1/userdocs/flow/how-does-it-work.html) doch nichts gegen die Speicherung in Datenbanken:


Trotzdem sind Continuations an einem Thread gebunden, der fortlaufend erhalten bleiben muss. Ob du die Daten von dort aus aus einer DB holst, spielt keine Rolle. Deine Anwendung kann nicht mehr skalieren.

[Crushinator]

Woraus entnimmst Du, daß ein Continuation-Object zwingend an einem Thread gebunden sein soll? Das würde doch dem Konzept von Load balancing widersprechen. Zur Vermeidung von wartenden Threads sollte man sendPage() vewenden nach dem man das WebContinuation-Object zuvor in einer Datenbank gesichert hat.

[edit]
*Thema hierhin gesplittet*

[grakaman]

Woraus entnimmst Du, daß ein Continuation-Object zwingend an einem Thread gebunden sein soll? Das würde doch dem Konzept von Load balancing widersprechen. Zur Vermeidung von wartenden Threads sollte man sendPage() vewenden nach dem man das WebContinuation-Object zuvor in einer Datenbank gesichert hat.

[edit]
*Thema hierhin gesplittet*

In der Dokumentation steht, dass sendPageAndWait die Ausführung anhält. Und ohne dieser Anweisung ist doch das ganze continuations vollkommen sinnlos, da es ja um Workflow geht.
Egal, man braucht kein Continuations, um das selbe Ergebnis zu erzielen.

[HellHorse]

Trotzdem sind Continuations an einem Thread gebunden, der fortlaufend erhalten bleiben muss. Ob du die Daten von dort aus aus einer DB holst, spielt keine Rolle. Deine Anwendung kann nicht mehr skalieren.
Nee, der Witz an der ganzen Geschichte ist ja, das die continuation "den Stack enthält", so kannst den Zustand jederzeit wiederherstellen.
Du kannst einen Thread nicht "zurückrollen".
Scheme continuations get stored in the user session of the J2EE application server.
Bin ich der einzige, der dies pervers findet?

[grakaman]

Nee, der Witz an der ganzen Geschichte ist ja, das die continuation "den Stack enthält", so kannst den Zustand jederzeit wiederherstellen.
Du kannst einen Thread nicht "zurückrollen".

Bin ich der einzige, der dies pervers findet?

Den Zustand kann ich auch so jederzeit wieder herstellen, indem ich das Objekt einfach serialisiere und abspeichere und selbst das brauch ich nicht mal machen, weil das automatisch für mich erledigt wird.

[HellHorse]

Den Zustand kann ich auch so jederzeit wieder herstellen, indem ich das Objekt einfach serialisiere und abspeichere und selbst das brauch ich nicht mal machen, weil das automatisch für mich erledigt wird.
Zustand des Kontrollflusses (das richtige Wort fällt mir gerade nicht ein :() inkl. Stack etc wollte ich sagen.

[grakaman]

Zustand des Kontrollflusses (das richtige Wort fällt mir gerade nicht ein :() inkl. Stack etc wollte ich sagen.

Die continuations fangen ja genau dort an, wo du sie erst explizit gespeichert hast und die Verarbeitung abgebrochen wurde. Also kannst du solche Abschnitte logischerweise in Methoden packen und z.B. mittels Reflections dann aufrufen. Zumal ich diesen Kontrollfluss wie bei dem cocoon Bsp. nicht gerade gut fande, da er sehr prozedural ist. Wenn mein Viewcontroller auf einen entsprechenden Modelcontroller zugreift und dieser z.B. mit Events des Objektes kommuniziert, brauche ich nicht mal Reflections.

[HellHorse]

Irgendwie habe ich das Gefühl du hast nicht richtig verstanden, was eine Continuation ist.

Folgendes Beispiel:
Wichtig ist nur die step-k Funktion ganz unten. up und down sind Hilfsfunktionen. Der Rest entspricht der Implementation von makeStackSnapshotAndDircard (siehe weiter unten).

(define INVOKE/NO-CONT '*invoke/no-cont*)

(define make-INVOKE/NO-CONT
(lambda ()
((call/cc
(lambda (k^)
(set! INVOKE/NO-CONT (lambda (th) (k^ th)))
(lambda () 'INVOKE/NO-CONT))))))

(make-INVOKE/NO-CONT)

(define nothing 'nothing)
(define (escaper)
(lambda () (INVOKE/NO-CONT (lambda() (set! nothing 'nothing)))))

(define get-back #f)
(define (break)
(call/cc (lambda (k)
(set! get-back (lambda () (k)))
((escaper)))))

(define (up n)
(display "up ")
(display n)
(newline))

(define (down n)
(display "down ")
(display n)
(newline))

(define (step-k n)
(up n)
(if (= n 3)
(break))
(if (> n 0)
(step-k (- n 1)))
(down n))

In Java:

public class ContinuationDemo {
private Conitunation getBackContinuation;

public void step-k(int n) {
System.out.println("up "+n);
if (n == 3) {
this.getBackContinuation = makeStackSnapshotAndDircard();
}
if (n >= 0) {
this.step-k(n - 1)
}
System.out.println("down "+n);
}

public void getBack() {
this.getBackContinuation.run();
}
}

In Prosa:
Das einzige was einer Erklärung bedraf ist wohl die schon erwähnte makeStackSnapshotAndDircard Methode. Diese Methode macht einen Snapshot vom aktuellen Stack und weist eine Referenz darauf der Instanzvariable getBackCont zu. Danach wird der aktuelle Stack verworfen und nicht einfach bloss die Ausführung unterbrochen.
Später kann dann der Stack zum Zeitpunkt als makeStackSnapshotAndDircard aufgerufen wurde mittels Aufruf der run Methode wieder hergestellt werden (und der jetzt aktuelle verworfen werden).

Was produziert das Ganze?
Wenn man step-k mit dem Argument 5 aufruft:

> (step-k 5)
up 5
up 4
up 3

Wir können step-k natürlich danach wieder aufrufen, auch mit einem anderen Paramter als 5.

Wenn man danach get-back aufruft:

> (get-back)
up 2
up 1
up 0
down 0
down 1
down 2
down 3
down 4
down 5

Wenn man get-back dannach noch einmal aufruft, ist der output der gleiche (Annahme das letzte mal als man get-back aufrief war der Parameter 5). Da einfach noch einmal der gleiche Zustand wiederhergestellt wird.
Es ist dabei nicht entscheidend, dass immer die gleiche Funktion aufgerufen wird, ich tat dies bloss der Übersichtlichkeit halber.

Um wirklich zu beweisen, dass wir auf den Stack arbeiten und nicht irgendwie mit Threads und locks tricksen, folgendes:

(define (proof)
(display "should display")
(newline)
(get-back)
(display "should not display"))

führt natürlich zu der Ausgabe:

should display
up 2
up 1
up 0
down 0
down 1
down 2
down 3
down 4
down 5


Mich würde doch sehr wunder nehemen, wie du das mit Reflection machen willst.

[grakaman]

Ich verstehe das Prinzip von Continuations, es ist für mich nur vollkommen überflüssig in einer objekt orientierten Umgebung. Ich finde es auch äußerst schlecht, einen festen Ablauffluss in die Logik zu implementieren. Das Objekt hat sich überhaupt nicht darum zu kümmern, es soll nur in deinem Bsp. Werte addieren und ggf. Ereignisse auslösen.
Und mit Reflections meinte ich das so, dass du ja die Logik in einem Objekt in Methoden organisierst und nicht so prozedural programmierst wie in deinem Bsp. oder allen anderen Continuation Beispielen. D.h. ich serialisiere mein Objekt und muss mir, wen ich denn diesen prozeduralen Weg gehen möchte, merken, welche Methode ich als nächstes in der Verarbeitungsreihenfolge aufrufe. Und das Aufrufen könnte ich, um es dynamisch zu gestalten, mit Reflection lösen. Ich bekomme zwar nicht den Stack gespeichert, aber ich sehe auch nicht, wozu ich das bräuchte, um die selben Resultate zu liefern, da ich das Problem anders lösen würde.

[Trap]

Natürlich kann man das ganze auch anders erreichen, das kann man immer.

OO ist nach deiner Argumentation genauso überflüssig wie continuations. Man kann jederzeit selbst ein Objektsystem implementieren.

Die Fragen die mir wichtig erscheinen sind:
1) Wird diese Art von Funktion oft benutzt?
2) Ist die gleiche Funktionalität mit continuations einfacher und direkter zu erreichen als über die bisher angebotenen Mittel?
3) Ist die Performance mindestens gleichwertig?

[grakaman]

Natürlich kann man das ganze auch anders erreichen, das kann man immer.

OO ist nach deiner Argumentation genauso überflüssig wie continuations. Man kann jederzeit selbst ein Objektsystem implementieren.

Die Fragen die mir wichtig erscheinen sind:
1) Wird diese Art von Funktion oft benutzt?
2) Ist die gleiche Funktionalität mit continuations einfacher und direkter zu erreichen als über die bisher angebotenen Mittel?
3) Ist die Performance mindestens gleichwertig?

Seit wann müssen sich bewährte Techniken an Continuations messen? Wozu brauche ich denn Continuations, was man nicht auch wie bisher lösen könnte?
Meiner Meinung nach passt das auch nicht recht in die oo Denkweise.

[Xmas]

Erinnert mich irgendwie ein bisschen an Generator-Funktionen, und dasselbe könnte man wohl auch mit jenen realisieren. Nur sind die Generatoren eigentlich zum Iterieren über möglicherweise sehr ressourcenfressende Objekte gedacht.

[HellHorse]

Nächste Runde:
Ich verstehe das Prinzip von Continuations, es ist für mich nur vollkommen überflüssig in einer objekt orientierten Umgebung.
Klar, darum haben die Seaside Jungs ja auch continuations in Smalltalk implementiert. Aber vermutlich ist Smalltalk halt einfach keine objektorientierte Umgebung.
Dir ist schon klar, dass weder C++, noch Java, noch C# objektorientierte Sparchen sind? Sie erlauben dir lediglich objektorientiert zu programmieren.
Scheme erlaubt es dir recht einfach (Aufwand in der Grössenordnung von einem Nachmittag) ein eigenes Objektsystem zu implementieren und ist dann genauso "objekt orientiert" wie C++, Java und C#. Darum hat es im Gegensatz zu CommonLISP keines.
Wenn du schon so mit oo und Kontrollfluss kommst, dann programmiere gefälligst in einer objektorientierten Programmiersprache ohne if wie Smalltalk und benutze ein Betriebssystem das Wert auf oo legt wie BeOS.
Ich finde es auch äußerst schlecht, einen festen Ablauffluss in die Logik zu implementieren.

Ich sehe den Zusammenhang zwischen continutaions und festem Kontrollfluss nicht. Ich kann ja beliebig viele continutions haben, kann sie aufrufen, oder es sein lassen. Ich kann den continuations sogar Argumente übergeben:

(define test #f)
(if (>= (+ 5 (call/cc (lambda (k) (set! test k) (k 0)))) 0)
(display "bigger than zero")
(display "not bigger than zero"))

Zur Erinnerung: wir reden hier von LISP

Und mit Reflections meinte ich das so, dass du ja die Logik in einem Objekt in Methoden organisierst und nicht so prozedural programmierst wie in deinem Bsp.
funktional bitte,
Zur Erinnerung: wir reden hier von LISP
Man kann in Scheme auch imperativ oder oo programmieren, wenn man will. Genauso wie in C++, Java und C#, wenn mal will.
Zudem hat LISP im Gegenstatz zu C++ und Java (C# höchstwahrscheinlich auch nicht) den Segen von Alan Kay.

oder allen anderen Continuation Beispielen. D.h. ich serialisiere mein Objekt und muss mir, wen ich denn diesen prozeduralen Weg gehen möchte, merken, welche Methode ich als nächstes in der Verarbeitungsreihenfolge aufrufe. Und das Aufrufen könnte ich, um es dynamisch zu gestalten, mit Reflection lösen.
Wäre es dir lieber, wenn ich in Zukunft von einem continuation Objekt spreche?
Um dich zu beruhigen, continuations und oo widersprechen sich nicht, siehe Seaside.

Ich bekomme zwar nicht den Stack gespeichert,
Zu einer Berechnung zu einem best. Zeitpunkt gehört nun mal der Stack. Natürlich kannst du etwas machen, das sich in einem best. Zeitpunkt so verhält, das gleiche ist es trotzdem nicht.

Die Fragen die mir wichtig erscheinen sind:
1) Wird diese Art von Funktion oft benutzt?
IMO müsste es heissen:
Wenn man es braucht, wieviel Implementationsaufwand erspart es einem?
Frag doch sonst mal die Perl Jungs, warum sie es in Version 6 wollen.

2) Ist die gleiche Funktionalität mit continuations einfacher und direkter zu erreichen als über die bisher angebotenen Mittel?
Mit dem Missbrach von Exceptions kannst du einen Teil simulieren.
Der Rest: sprich mal mit den Seaside oder Perl Jungs oder mach einen eigenen Vorschalg.

3) Ist die Performance mindestens gleichwertig?

Verstehe ich das richtig: du machst auch keinen array-range check, bloss weil die Performance nicht mindestens gleichwertig ist?
Eine Berechung zu einen bestimmten Zeitpunkt abbrechen, weil ein Fortfahren keinen Sinn machen würde: Wie kann so etwas Performance kosten?
Eine Berechnung zu einem bestimmten Zeitpunkt in der Vergangenheit wieder aufnehmen ev. mit einem anderen Parameter anstatt die ganze Berechnung von vorne zu beginnen: Wie kann so etwas Performance kosten?
IIRC ist CPS etwas schneller in der Ausführung. Es viel langsamer zu schreiben und zu lesen.

[grakaman]

Wäre es dir lieber, wenn ich in Zukunft von einem continuation Objekt spreche?
Um dich zu beruhigen, continuations und oo widersprechen sich nicht, siehe Seaside.


Ich finde schon, dass es sich widerspricht, denn in allen Bsp. wird ja ein prozeduraler Programmablauf implementiert. Ansonsten bräuchte ich ja kein Continuations. Der mir primär erscheinende Zweck ist nur den Status in einem prozeduralen Ablauf zu recovern, was dort eben nur über den Stack geht. Trotzdem, und das ist für mich der entscheidende Punkt, geht das ganze nicht dynamisch und du musst an bestimmten Stellen explizit Speicherpunkte setzen. Das ist im Prinzip nichts anderes, als deine Logik aufzuteilen, was man eben z.B. in objekt orientierter Sichtweise in mehreren Methoden und Ereignissen eines Objektes organisiert.



Zu einer Berechnung zu einem best. Zeitpunkt gehört nun mal der Stack. Natürlich kannst du etwas machen, das sich in einem best. Zeitpunkt so verhält, das gleiche ist es trotzdem nicht.


Wie schon erwähnt, es ist imo mit einem anderen Ansatz für das Ergebnis recht belangenlos, ob du den Stack speicherst oder aber z.B. ein statusloses Objekt mit gespeicherten Werten neu aufrufst. Das Ergebnis wird durch Continuations nicht besser.


IMO müsste es heissen:
Wenn man es braucht, wieviel Implementationsaufwand erspart es einem?
Frag doch sonst mal die Perl Jungs, warum sie es in Version 6 wollen.


Tja, wenn ich mir das Bsp. auf der Cocoon Website oder deins anschaue, dann halte ich den Implementierungsaufwand für recht fragwürdig. Gravierender ist es imo aber bei Webapplikationen, da halte ich es sogar für recht sinnlos, da ich da z.B. mit Session Objekten tausend mal schneller bin.
Und was die Performance betrifft, ich kann mir nicht wirklich vorstellen, dass die Mengen an Daten zum Serialisieren des gesamten Stacks und das Wiederherstellen schneller als bisherigen Verfahrensweisen sind. Es wird wohl sogar bedeutend langsamer sein.

[HellHorse]

Ich finde schon, dass es sich widerspricht, denn in allen Bsp. wird ja ein prozeduraler Programmablauf implementiert. Ansonsten bräuchte ich ja kein Continuations. Der mir primär erscheinende Zweck ist nur den Status in einem prozeduralen Ablauf zu recovern, was dort eben nur über den Stack geht. Trotzdem, und das ist für mich der entscheidende Punkt, geht das ganze nicht dynamisch und du musst an bestimmten Stellen explizit Speicherpunkte setzen. Das ist im Prinzip nichts anderes, als deine Logik aufzuteilen, was man eben z.B. in objekt orientierter Sichtweise in mehreren Methoden und Ereignissen eines Objektes organisiert.
Wo liegt denn der Unterschied, ob du einen Methodenaufruf, der dutzende andere Methodenaufrufe nach sich zieht oder ein Funktionsaufruf der dutzende andere Funktionsaufrufe nach sich zieht unterbrichst?
Und LISP ist eine funktionale Programmiersprache.

Wie schon erwähnt, es ist imo mit einem anderen Ansatz für das Ergebnis recht belangenlos, ob du den Stack speicherst oder aber z.B. ein statusloses Objekt mit gespeicherten Werten neu aufrufst. Das Ergebnis wird durch Continuations nicht besser.
Der Vorteil von continuations gegenüber einem anderen Murks ist ja, dass du nicht speziell darauf programmieren musst, dass der Ablauf irgendwo unterbrochen wird. Falls du ihn unterbrechen willst, ein call/cc, ein lambda, continuation speichern und eine escape Funktion/Methode aufrufen das wars. Du kannst selbstverständlich diese Sachen in ein Funktion/Methode zusammenfassen und dann ist es nur noch ein Aufruf.
Du kannst das problem "straight forward" lösen und dann noch continuations hinzufügen.

Tja, wenn ich mir das Bsp. auf der Cocoon Website oder deins anschaue, dann halte ich den Implementierungsaufwand für recht fragwürdig.
Ein call/cc um den Kontext zu erzeugen, eine lambda um das Argument für voriges zu erzeugen und ein set! um die continuation zu speichern und eventuell eine escape Funktion aufrufen. Das Ganze Zusammengefasst in einer Funktion. Jetzt mal ehrlich, was willst du da noch vereinfachen?

Gravierender ist es imo aber bei Webapplikationen, da halte ich es sogar für recht sinnlos, da ich da z.B. mit Session Objekten tausend mal schneller bin.
Letzhin habe ich eine Präsentation von jemandem gesehen, die mit Seaside eine Webapplikation für eine schweizer Versicherung in etwas mehr als zwei Monaten erstellt haben. Die behaupteten vergleichbare Webapplikationen für andere Versicherungen, die von anderen Firmen ohne den Einsatz von continuations erstellt wurden, hätten mit grösseren Teams über ein Jahr gebraucht.
Die haben Erfahrung mit continuations und halten der Produktivitätsvorteil für gravierend.

Ich halte es nicht für sinnlos, wenn ich eine Webapplikation wie eine normale Applikation programmieren kann, und es keinen Unterschied macht, ob ich ein Widget oder eine Seite darstelle und mich nicht mit so low-level Kram wie Sessions rumschlagen muss. Wenn der back-Button automatisch so funktioniert wie man es erwartet und die Webapplikation normal weiterarbeitet wenn sie irgendwann auf zwei Browserfenster verteilt wird.

Und was die Performance betrifft, ich kann mir nicht wirklich vorstellen, dass die Mengen an Daten zum Serialisieren des gesamten Stacks und das Wiederherstellen schneller als bisherigen Verfahrensweisen sind. Es wird wohl sogar bedeutend langsamer sein.
Das sind ja bloss lambda-Ausdrücke. Ob ich die oder Objekte serialisiere, sollte wohl keinen so grossen Unterschied machen.

@Xmax
Ja, generators lassen sich einfach mit continuations erzeugen, ohne irgendwelche Magie. Ebenso wie Suchprobleme, wo man später einfach an einem bestimmten Ort weitersuchen kann und nicht von vorne beginnen muss.
Ebenso lässt es sich alls verallgemeinertes try-catch verwenden.

[grakaman]

Wo liegt denn der Unterschied, ob du einen Methodenaufruf, der dutzende andere Methodenaufrufe nach sich zieht oder ein Funktionsaufruf der dutzende andere Funktionsaufrufe nach sich zieht unterbrichst?
Und LISP ist eine funktionale Programmiersprache.


Der Unterschied liegt darin, dass Ein Objekt mit entsprechenden Methoden und Ereignissen aus oo Sicht wiederverwendbar ist und die Logik überhaupt nichts vom Ablauf wissen darf. Und das ist auch imo das Problem von Continuations, da es das Mixen von Logik und Prozessabläufen fördert, denn sonst wäre es meiner Meinung nach recht überflüssig. Persistenzframeworks gibt es ja wie Sand am Meer und UI Prozess Komponenten sind in MultiLayer Architekturen auch nichts neues. Und da komme ich auch zum nächsten Punkt, UI Prozesskomponenten aus oo Sicht sind nämlich mit Continuations schlecht möglich. Als Bsp. nehme ich wieder cocoon, dort sendest du explizit Webpages und rufst dann die Werte ab. Wenn deine Webpages komplexer werden, musst du die Logik ja auch irgendwo unterbringen. Das kannst du ja schlecht in die continuations Komponente einbauen, da es wohl gar nicht möglich ist und wenn doch, du die grottigste Architekur auf Erden hast. Also gehe ich einmal davon aus, dass du dann Servlets oder anderes benutzt. Aber dann stellt sich wieder die Frage, warum du Logik in die Continuations Komponente schreibst, die logisch gesehen gar nichts damit zu tun hat, sondern ins Servlet gehört oder aber in einer Komponente, die das Servlet benutzt. Ich habe jetzt mal von Java gesprochen, da mir ja kein Continuation Bsp. für .NET vorliegt.


Der Vorteil von continuations gegenüber einem anderen Murks ist ja, dass du nicht speziell darauf programmieren musst, dass der Ablauf irgendwo unterbrochen wird.


Diese Programmierweise halte ich eher für großen Murks, da du Dinge vermischst, die aus logischer Sicht nicht zusammengehören. Und ich muss auch nicht darauf Programmieren, dass irgend etwas unterbrochen wird, sondern kapsel logische Einheiten in kleine Teile auf, so wie man es zuvor modeliert hat. Und den Rest erledigen Persistenzframeworks, Session Objekte etc. Und noch ein Wort zur Wiederverwendung, die ist ja mit Continuations sehr schlecht. Eine Continuations Komponente, z.B. bei Cocoon, kann ich schlecht in meiner Anwendung wiederverwenden, da ich dort erstens spezielle Webpages abrufe und genau an diese gebunden bin. Und zweitens kann ich diese Komponente dann auch nicht in meiner Windows Applikation meiner verteilten Anwendung wiederverwenden. Deswegen sind UI Prozess Komponenten, die auf einem sauberen Framework mit entsprechenden Schnittstellen basieren viel besser, als diese globale Betrachtungsweise, wie es Continuations macht.


Ich halte es nicht für sinnlos, wenn ich eine Webapplikation wie eine normale Applikation programmieren kann, und es keinen Unterschied macht, ob ich ein Widget oder eine Seite darstelle und mich nicht mit so low-level Kram wie Sessions rumschlagen muss. Wenn der back-Button automatisch so funktioniert wie man es erwartet und die Webapplikation normal weiterarbeitet wenn sie irgendwann auf zwei Browserfenster verteilt wird.


Bei ASP/ASP.NET speicherst du Sessions mit Session["Objekt"] = obj;
Das ist für mich tausend mal einfacher, als Persistenz durch Tricks wie das speichern des Stacks vorzutäuschen. Der Backbutton Effekt ist schon seit sehr vielen Jahren Gang und Gebe, inwieweit da Continuations etwas revolutionieren soll, ist mir absolut schleierhaft. Und eine Webapplikation programmiere ich schon jetzt ähnlich wie eine normale Applikation, das richtige Framework vorausgesetzt (z.B. ASP.NET), abgesehen von der deklarativen Seite.



Das sind ja bloss lambda-Ausdrücke. Ob ich die oder Objekte serialisiere, sollte wohl keinen so grossen Unterschied machen.


Auf dem Stack liegen auch Objekte (Primitives), zumindest ist das in gängigen OO Sprachen so. Wie das im speziellen bei LISP ist, weiß ich nicht. Hier geht es aber um Continuations allgemein.

[HellHorse]

nd das ist auch imo das Problem von Continuations, da es das Mixen von Logik und Prozessabläufen fördert, denn sonst wäre es meiner Meinung nach recht überflüssig.
Prozessorientierung und taskorientierte UIs ist aus oo Sicht sowieso gefährlich:
http://www.nakedobjects.org/section6.html

Ich habe jetzt mal von Java gesprochen, da mir ja kein Continuation Bsp. für .NET vorliegt.
Soviel ich weiss, basiert Cocoon Flow auf JavaScript es ist zwar möglich Java aufzurufen, mir ist aber keine Lösung für continuations in Java bekannt.


Bei ASP/ASP.NET speicherst du Sessions mit Session["Objekt"] = obj;
Das ist für mich tausend mal einfacher, als Persistenz durch Tricks wie das speichern des Stacks vorzutäuschen. Der Backbutton Effekt ist schon seit sehr vielen Jahren Gang und Gebe, inwieweit da Continuations etwas revolutionieren soll, ist mir absolut schleierhaft. Und eine Webapplikation programmiere ich schon jetzt ähnlich wie eine normale Applikation, das richtige Framework vorausgesetzt (z.B. ASP.NET), abgesehen von der deklarativen Seite.
Wenn du mit der jetzigen Situation zufrieden bist, hat es wohl wenig Sinn zu versuchen, dich von einer möglichen Verbesserung zu überzeugen.

[HellHorse]

*threadausgrab*
http://www-106.ibm.com/developerworks/library/j-contin.html
Einfach bloss der erste Teil, der continuations in Webapplikationen allgemein behandelt. In Cocoon (Flow) ist das Ganze irgendwie recht mühsam und bescheiden.
Sehr brauchbar dagegen ist imo Seaside (Link unten im Artikel). Am besten mal das sushi store Beispiel anschauen.