XE und XE2 - was ist so attraktiv daran?

[jaenicke]

Zitat von DSCHUCH:

bei xe3 sind wir sicher dabei, vor allem da wir uns weiterentwicklungen zb von sprachfeatures, im datasnap etc erhoffen, was wir doch inzwischen recht intensiv verwenden.

Da sind auch bei XE2 bereits wichtige Neuerungen dabei.
http://cc.embarcadero.com/item/28542
Bei 14:53 werden z.B. die Events für Heavyweight Callbacks gezeigt. Das heißt man hat jetzt überall, auch in JavaScript, Events, mit denen man auf einen Serverdisconnect usw. reagieren kann. Genau so etwas habe ich bei XE sehr vermisst.

[DSCHUCH]

Zitat von jaenicke:

Da sind auch bei XE2 bereits wichtige Neuerungen dabei.
http://cc.embarcadero.com/item/28542
Bei 14:53 werden z.B. die Events für Heavyweight Callbacks gezeigt. Das heißt man hat jetzt überall, auch in JavaScript, Events, mit denen man auf einen Serverdisconnect usw. reagieren kann. Genau so etwas habe ich bei XE sehr vermisst.

mit heavy-callbacks haben wir uns gerade erstmalig auseinandergesetzt und sofort vertagt. kann aber auch daran liegen das wir nicht also viel zeit hatten und die dinge noch nicht also gut dokumentiert sind. ^^
dazu werden wir demnächst nochmal einen post schreiben, evtl hat da jemand lösungsansätze. derzeit haben wir das aber erstmal wieder entfernt. verwenden wollen wir dieses feature aber alsbald möglich.

kurzer überblick unserer probleme:

1) technisch: sicherheit/verbindung, verschlüsselung, zusammensetzung verbindungsparameter mittels json. etc.
2) inhatlich: server selbst kann kein callback auslösen, ich brauche im server einen client der den broadcast auslöst. (zB Server meldet Speicher voll an alle angemeldeten Clients)

... passt nicht zum thema, wird ein posting geben.

[jaenicke]

Zitat von DSCHUCH:

server selbst kann kein callback auslösen, ich brauche im server einen client der den broadcast auslöst.

Doch das geht, auch bereits in XE. Mach mal deinen Thread auf. Und dieses Video könnte auch interessant sein, außerdem die Demo in den eigenen Dokumenten unter "RAD Studio\8.0\Samples\Delphi\DataSnap\CallbackChannel s".

[himitsu]

Ich sag das jetzt einfach mal so unverblühmt:
Dieser TDSClientCannelCallbackManager ist der größte Schrott, welchen ich bis jetzt erlebt hab, in der DataSnap-Welt.

Eigentlich wollte ich diese Woche schon einen Haßpost dazu veröffentlichen, aber ich hab mich dann doch erstmal dagegen entschieden und werde das in Ruhe nochmal (sachlichlicher) überarbeiten.

Grund:
Ist dir schonmal aufgefallen, daß es keinerlei direkte Verbindung zwischen der SQLConnection und dem CallbackManager besteht?
In allen Demos wird nur zufällig diese SQLConnection verwendet, weil sie die Einzige in dem ganzen Programm ist.
Nähere Gründe und Erklärungen folgen bald, auch zur "Sicherheit" der Datasnap-Verbindungen.