Neue Roadmap September 2017 veröffentlicht

[Uwe Raabe]

Embarcadero hat eine neue Roadmap veröffentlicht: https://community.embarcadero.com/article/16563

Hier tauchen auch schon die ersten Auswirkungen der Sencha-Übernahme auf.

[Der schöne Günther]

Mich interessiert das unter Research Area am meisten :-)

Gut dass "Raspberry PI / Windows ARM" immer noch auftaucht.

Ist "Delphi ARC model on Windows" neu? War das letztes mal schon drin? Dass man unter Windows noch kein ARC haben kann hält mich bislang wirklich davon ab etwas größeres in Sachen Multi-Plattform mit Delphi überhaupt anzugehen.

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1381428)

Hier tauchen auch schon die ersten Auswirkungen der Sencha-Übernahme auf.

Das wäre?

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1381434)

Zitat:

Zitat von Uwe Raabe (Beitrag 1381428)

Hier tauchen auch schon die ersten Auswirkungen der Sencha-Übernahme auf.

Das wäre?

RAD Server: Support for JavaScript Clients, including Sencha Ext JS clients

[Rollo62]

Was soll ich denn wohl unter "Windows ARM" verstehen, ist das wie .NET Core, ohne GUI ?

Rollo

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1381432)

Ist "Delphi ARC model on Windows" neu? War das letztes mal schon drin? Dass man unter Windows noch kein ARC haben kann hält mich bislang wirklich davon ab etwas größeres in Sachen Multi-Plattform mit Delphi überhaupt anzugehen.

Die Konstanten in PlatformConst.pas sind doch eine recht interessante Liste (man beachte WinNX32 oder die ARM-Varianten für Linux):

Zitat:

cWin32Platform = 'Win32';
cWinNX32Platform = 'WinNX32';
cWinIoT32Platform = 'WinIoT32';
cWinARMPlatform = 'WinARM';
cOSX32Platform = 'OSX32';
cWin64Platform = 'Win64';
cLinux32Platform = 'Linux32';
cAndroidPlatform = 'Android';
ciOSSimulatorPlatform = 'iOSSimulator';
ciOSDevice32Platform = 'iOSDevice32';
ciOSDevice64Platform = 'iOSDevice64';
ciOSDevicePlatform = ciOSDevice32Platform;
cLinux64Platform = 'Linux64';
cOSX64Platform = 'OSX64';
cLinux32ARMPlatform = 'Linux32ARM';
cLinux64ARMPlatform = 'Linux64ARM';
cAndroid64Platform = 'Android64';

[bra]

ARC für Windows ist doch schon länger ein Thema bei EMB. Ich meine, das war auf den vorherigen Roadmaps auch schon drauf als langfristiges Ziel.

[Rollo62]

Zitat:

cWinNX32Platform = 'WinNX32';
cWinIoT32Platform = 'WinIoT32';
cWinARMPlatform = 'WinARM';

Ja man sollte ab und zu mal in den Sourcen stöbern, wenn man doch noch Zeit dafür hätte :stupid:

Das IoT wird wohl für Headless gedacht sein, wie RasPi, aber könnte

Zitat:

cWinARMPlatform = 'WinARM';

etwa in Richtung Windows Phone gehen ?
Nicht das ich das momentan brauchen würde ...

Rollo

[RWarnecke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1381439)

Die Konstanten in PlatformConst.pas sind doch eine recht interessante Liste (man beachte WinNX32 oder die ARM-Varianten für Linux):

Zitat:

cWin32Platform = 'Win32';
cWinNX32Platform = 'WinNX32';
cWinIoT32Platform = 'WinIoT32';
cWinARMPlatform = 'WinARM';
cOSX32Platform = 'OSX32'; <--
cWin64Platform = 'Win64';
cLinux32Platform = 'Linux32';
cAndroidPlatform = 'Android';
ciOSSimulatorPlatform = 'iOSSimulator';
ciOSDevice32Platform = 'iOSDevice32'; <---
ciOSDevice64Platform = 'iOSDevice64';
ciOSDevicePlatform = ciOSDevice32Platform;
cLinux64Platform = 'Linux64';
cOSX64Platform = 'OSX64';
cLinux32ARMPlatform = 'Linux32ARM';
cLinux64ARMPlatform = 'Linux64ARM';
cAndroid64Platform = 'Android64';

Da fallen mir doch gleich mal zwei Einträge auf, der erste Eintrag ab 25.09.2017 und den anderen Eintrag ab morgen kann man dann getrost vergessen.

[Redeemer]

Zitat:

Zitat von Rollo62 (Beitrag 1381441)

Zitat:

cWinARMPlatform = 'WinARM';

etwa in Richtung Windows Phone gehen ?
Nicht das ich das momentan brauchen würde ...

Rollo

Auch Windows 10 läuft auf ARM. Daneben noch Windows RT (=Windows 8).

[Rollo62]

Ja das meine ich ja.
Aber Emba wollte das (noch) nicht unterstützen.

Oder ist das jetzt der erste Schritt, headless, wie bei Linux,
und der Rest wird dann von FmxLinux erledigt :stupid:

Spannend spannend ...

Rollo

[Bernhard Geyer]

Zitat:

Zitat von Redeemer (Beitrag 1381447)

Zitat:

Zitat von Rollo62 (Beitrag 1381441)

Zitat:

cWinARMPlatform = 'WinARM';

etwa in Richtung Windows Phone gehen ?
Nicht das ich das momentan brauchen würde ...

Rollo

Auch Windows 10 läuft auf ARM. Daneben noch Windows RT (=Windows 8).

Win10 läuft nicht komplett auf ARM. Nur die Subsysteme die schon immer unter ARM liefern.
x86 und x64 laufen nicht unter ARM. Damit ist nix mit Delphi und Co.

[mkinzler]

x86 soll emuliert werden. Die ersten Win10 Geräte, welche auf dem SD835 basieren sollen, werden demnächst auf den Markt kommen. Intel hat aber schon mit einer Klage gedroht.

https://www.qualcomm.com/news/onq/20...eiled-computex

[Bernhard Geyer]

Es gibt scheinbar in Zukunft 3 Ausbaustufen:

Windows Desktop Developers (Sollte die aktuelle Pro, hoffentlich ohne jegliche Funktionsreduktion) sein

Mobile Develpers (Pro + Mobile AddOn)

Enterprise Developers (Enterprise + Architect?)

[mkinzler]

Zitat:

Windows Desktop Developers (Sollte die aktuelle Pro, hoffentlich ohne jegliche Funktionsreduktion) sein

Hoffe ich auch, allerdings vermute ich, das man wieder versuchen wird, die Datenbankunterstützung auszubauen.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1381455)

x86 soll emuliert werden. Die ersten Win10 Geräte, welche auf dem SD835 basieren sollen, werden demnächst auf den Markt kommen. Intel hat aber schon mit einer Klage gedroht.

https://www.qualcomm.com/news/onq/20...eiled-computex

Die Frage ist ob das in 2017/18 noch irgendjemand interessiert?
Die Nachfrage nach "ich will meine 15 Jahre alte Desktop-Anwendung auf dem Smartphone laufen lassen" dürfte doch mittlerweile eher nur noch ein Nerd-Thema sein.

[mkinzler]

Es geht nicht um Smartphones, sondern um vollständige Rechner mit Arm-Prozessoren.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1381457)

Zitat:

Windows Desktop Developers (Sollte die aktuelle Pro, hoffentlich ohne jegliche Funktionsreduktion) sein

Hoffe ich auch, allerdings vermute ich, das man wieder versuchen wird, die Datenbankunterstützung auszubauen.

Pro ohne DB-Unterstützung ist sinnlos.
Da müssten wir unsere Wartung kündigen.

[mkinzler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381460)

Pro ohne DB-Unterstützung ist sinnlos.
Da müssten wir unsere Wartung kündigen.

Sehe ich auch so. Für mich hat die Unterstützung von Datenbanken auch nichts mit Enterprise zu tun. EMBT sieht das aber leider anders.

[mensch72]

Sinnvoll aber wohl "zu einfach" wäre dies:

Desktop Developers = ClientDB + VCL + Linux + OSX
Mobile Developers = ClientDB + Android + IOS + ?IOT?
Enterprise Developers = ServerDB + "Desktop"+"Mobile"

[Der schöne Günther]

Ich hätte aus der einen Folie jetzt nicht rausgelesen dass man Starter/Pro/Enterprise/Architect gegen etwas anderes ersetzt. Das sollten doch auf der Folie nur thematische Gruppierungen sein?

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1381487)

Das sollten doch auf der Folie nur thematische Gruppierungen sein?

So isses

[Rollo62]

Zitat:

Sinnvoll aber wohl "zu einfach" wäre dies:

Desktop Developers = ClientDB + VCL + Linux + OSX
Mobile Developers = ClientDB + Android + IOS + ?IOT?
Enterprise Developers = ServerDB + "Desktop"+"Mobile"

Sinnvoll für wen, EMBA ?

Wenn das so wäre bin ich raus.
Ich kämpfe schon jeden Tag genug mit BugFixing um dem Ganzen noch mhr Geld hinterherzuwerfen.

Der richtige Schritt von Emba wäre wenn Sie die Enterprise zum Preis der Pro anbieten würden,
damit noch mehr Kuden auf Delphi aufspringen.
Denn jeder Versuch den Kuchen Aufzuteilen macht doch keinen Sinn bei der kostenlosen Konkurrenz.
Wer würde sich denn Desktop + Mobile kaufen, nur um die mindest nötigen Platformen zu haben ?

Wie schonmal gesagt: Enterprise is gut und schön, aber auch da bei jeder neuen Version iOS, Android, Win10, OSX, XCode, .... fängt das große Zittern an.
Eigentlich müssten wir für den Stress von Apple, Google, M$, Emba, usw. Schadenersatz bekommen ...

Rollo

[mkinzler]

Zitat:

Wenn das so wäre bin ich raus.

Ist doch schon so. Die FireDAC-Version, welche bei der pro dabei ist ist nur für lokale Verbindungen geeignet.

[Bernhard Geyer]

Zitat:

Zitat von Rollo62 (Beitrag 1381506)

Zitat:

Sinnvoll aber wohl "zu einfach" wäre dies:

Desktop Developers = ClientDB + VCL + Linux + OSX
Mobile Developers = ClientDB + Android + IOS + ?IOT?
Enterprise Developers = ServerDB + "Desktop"+"Mobile"

Sinnvoll für wen, EMBA ?

Wenn das so wäre bin ich raus.
Ich kämpfe schon jeden Tag genug mit BugFixing um dem Ganzen noch mhr Geld hinterherzuwerfen.

Aktuell hat man Pro, Enterprise und Architekt und für die Pro noch das Mobile und FMX-Paket.

Aber ich sehe hier auf der Folie "Focus Area". Ist dann wohl doch nicht eine neue Aufteilung der Plattformen.
Und bei der Mobile-Spalte stand auch Windows

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1381507)

Zitat:

Wenn das so wäre bin ich raus.

Ist doch schon so. Die FireDAC-Version, welche bei der pro dabei ist ist nur für lokale Verbindungen geeignet.

Sind seit Jahren mit Pro + Devart mehr als zufrieden.
Solange TDataset nicht raufliegt ist alles gut.

[mkinzler]

Zitat:

Sind seit Jahren mit Pro + Devart mehr als zufrieden.

Gilt auch für mich.

[Lemmy]

vor einiger Zeit (Jahren) wurde in einer Emba-Umfrage mal das Thema Modularisierung angesprochen, d.h. ein individuell zusammengestelltes Delphi. Das kann man ziemlich weit treiben, aber im Grunde würde doch reichen:
Prof. Basisversion ohne DB Komponenten (und reduzierter Preis, also so was wie früher die Standard) dazu AddOns
* lokale Datenbanken
* C/S Datenbanken
* Mobile
* Linuxplattform
* OSx Plattform

Enterprise fasst dann alles zusammen + zusätzliche Komponenten und Tools.

Leider findet Embarcadero, dass das uns alle völlig überfordern würde und setzt das zum Schutz der eigenen Kunden nicht um. Ich finde das schade, hätte doch letztlich jeder so eine Version die seinen Anforderungen am besten erfüllt

[mensch72]

wenn ich die LongTermTargets von Emba sehe, im Vergleich was da mit ganz wenigen Zusatzmegabytes an Code ein paar Spezialisten in wirklich kurzer Zeit sehr stabil und kompatibel hin bekommen haben..

http://fmxlinux.com/
"toll", war aber zu erwarten das dies geht weil FMX ja dazu da, die GUI beliebig zu kapseln


http://www.crossvcl.com/
"genial", weil DAS IST DER WEG UM ZIG MIO VCL GUI-CodeZeilen mit OSX und Linux nutzbar zu machen... wenn es 1:1 klappt hat man gewonnen, wenn geht man im Einzelfall zu "fmxlinux"


Ich habe für 2018 mein Zeit&Geld-Budget auf die Porttierung einer wirklich großen und alten Anwendung(PascalFeatureStand "D2007") darauf ausgerichtet. Der für das erste Release gut funktionierende LinuxCompiler von Tokyo10.2.x ist bei uns immernoch das einzige Feature was wir vom aktuellen Delphi nutzen.
Sowohl VCL-Desktop als auch Mobile setzen wir bei bei uns Stand heute weiter auf Berlin10.1u2. Wir hoffen weiter auf ein bald kommendes 10.2.2 was unter Android und IOS "gleich gut 10.1u2" funktioniert... alles wir bekantlich gut damit spätetens bei 10.3.0(RTM) das Spiel von vorn los geht:)

[Rollo62]

Modularisierung wäre ja OK, wenn es sich am Ende des Tages nicht auf die Preise auswirkt.

So richtig viel Sinn sehe ich darin aber auch wieder nicht, höchstens um mal die Interna zu entschlacken.
Denn die Modularisierung wird uns sicher wieder eine Potenz mehr an Problemen bescheren ...
Wozu ?

Ich verstehe das VCL-only Kunden nicht unbedingt für FMX bezahlen wollen, aber da muss ich auch sagen das ein bischen in die Zukunft zu investieren nicht verkehrt ist.
FMX ist meiner Meinung nach sehr schön geeignet für eine schnelle Protierung von VCL,
jetzt mal nur für Windows gesprochen.
Leider hat FMX hier und da noch so seine Probleme, das sollte gefixt werden.
Es kann ja nicht sein das es schon bei den untersten Primitiven immer mal wieder Probleme gibt, wo man dann als Programmierer statt der App das Framework fixen muss.

Das in Zukunft niemand mehr an Apps vorbeikommt sollte aber auch mittlerweile jedem klar sein.
Der Tag wird kommen wo auch eine VCL-App ein Feature braucht was es nur auf Mobile gibt,
dann wäre ein sanfter Übergang sehr sinnvoll.

Das Theme ExtJS finde ich auch sehr spannend, weil da endlich ein Weg raus aus Label, Edit, Memo gezeigt wird.
In JS sind mittlerweile so gigantische Dinge möglich, was ich niemals von HTML erwartet hätte, und das viel flexibler als mit TControl.
Leider braucht man dazu einen Node.js oder ähnliches, was eine Applikation sicherlich aufbläht.
FMX + JS wäre sicher meiner Wunschliste um Styling auch mit CSS machen zu können, wenn es sich denn elegant in Delphi integrieren lässt.
So in der Richtung UI-Views supermodern, effektiv und CrossPlatform mit HTML5/JS/CSS und
Businesslogik schnell, sicher und bewährt mit Pascal/C++.
So dass man auch mal von der ganzen JS Welle mitprofitieren kann.
Im Moment scheint der Fokus JS ja eher auf RadServer zu sein, der für mich schon am Pricingmodell scheitert.


Rollo

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381509)

Sind seit Jahren mit Pro + Devart mehr als zufrieden.

Das kostet (vermute ich angesichts der Preisliste) allerdings mehr als die Enterprise mit FireDAC, nur dass wir mit der Enterprise auch gleich noch mehr Features wie mobile Entwicklung haben. Insofern macht für uns etwas anderes als die Enterprise gar keinen Sinn.

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1381536)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381509)

Sind seit Jahren mit Pro + Devart mehr als zufrieden.

Das kostet (vermute ich angesichts der Preisliste) allerdings mehr als die Enterprise mit FireDAC, nur dass wir mit der Enterprise auch gleich noch mehr Features wie mobile Entwicklung haben. Insofern macht für uns etwas anderes als die Enterprise gar keinen Sinn.

allein die 2.700€ die für einen Umstieg von Prof auf Enterprise fällig werden sind schon mal ein Statement (trotz Wartungsvertrag). Wenn man dazu nicht Unidac benötigt sondern nur ein, zwei SQL Datenbanken unterstützt, dann sieht die Rechnung ganz anders aus.... Dazu werden bei Devart die Komponenten von Delphi 6/7 bis zur jeweils aktuellen Version gepflegt, das ist bei Firedac nicht so.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1381536)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381509)

Sind seit Jahren mit Pro + Devart mehr als zufrieden.

Das kostet (vermute ich angesichts der Preisliste) allerdings mehr als die Enterprise mit FireDAC,...

Nö. Ich rechne mal Jährliches Update:

Pro (Update) - 1200 €(Pro Entwickler)
Unidac Pro Site - 1250 € (Firmenweit). Pro Entwickler bei uns dann ca. 200 €
ca. 1400 € pro Entwickler und Jahr


Enterprice - 2000 €



Hmmm.

Der Hauptvorteil für uns ist das wir mit den DevArt-Komponenten Updates bekommen ohne die gesamte IDE-Version hochziehen zu müssen.
Und AFAIK benötigt FireDAC die mysqllib.dll -> Oracle GPL-Falle!

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381547)

Nö. Ich rechne mal Jährliches Update:

Pro (Update) - 1200 €(Pro Entwickler)
Unidac Pro Site - 1250 € (Firmenweit). Pro Entwickler bei uns dann ca. 200 €
ca. 1400 € pro Entwickler und Jahr


Enterprice - 2000 €

Wir zahlen für die Enterprise etwas mehr als 700€ pro Entwickler und Jahr für die Subscription. Das wäre heute bei einem Neueinstieg sicherlich teurer als noch vor 5 Jahren, aber so viel teurer sicherlich nicht.
Der Einstiegspreis beim Wechsel zu Enterprise ist natürlich hoch (und man fällt dann aus dem günstigeren Alt-Vertrag heraus), was ich an verschiedenen Stellen schon bemängelt habe. Vielleicht gibt es da ja mal eine Lösung...

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381547)

Und AFAIK benötigt FireDAC die mysqllib.dll -> Oracle GPL-Falle!

Das Thema gab es hier ja schon. Solange man nicht fest gegen MySQL entwickelt und ein entsprechendes allgemeines Framework (wie es FireDAC ja ist) zum Datenbankzugriff benutzt, gibt es kein Problem. Allerdings benutzen wir MariaDB.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1381550)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1381547)

Und AFAIK benötigt FireDAC die mysqllib.dll -> Oracle GPL-Falle!

Das Thema gab es hier ja schon. Solange man nicht fest gegen MySQL entwickelt und ein entsprechendes allgemeines Framework (wie es FireDAC ja ist) zum Datenbankzugriff benutzt, gibt es kein Problem. Allerdings benutzen wir MariaDB.

Das kann du ja einen Oracle-Rechtsanwalt erklären, wenn dieser der Meinung ist das die harte Bindung an die libmysql.dll schon genügt, auch wenn du auch noch MS SQL-Server und Co. unterstützt.
Und wenn dann auch der Richter noch Konzernfreutig entscheidet hilft es dir nicht wenn FSF und Co. anderer Meinung sind.

Mitlerweile ist da ja nicht mehr so schlimm, wenn man die DLL von MariaDB verwendet. Dürfte in vielen Fällen auch auf MySQL Zugriff ermöglichen.

[jaenicke]

Da habe ich MySQL und MariaDB auch verwechselt, nur bei letzterem steht das explizit drin. Das war auch beim letzten Mal das Ergebnis, hatte ich vergessen, Sorry. :oops:

Ich hätte für die Roadmap jedenfalls schon noch einige Ideen, aber am wichtigsten wäre erst einmal, wenn alles sauber läuft. Insbesondere fallen mir da Refactoring und Error Insight ein (auch wenn bei letzterem ja schon einiges korrigiert wurde, aber halt noch nicht alles).