I was wondering about something I can't try for myself (using Berlin and there is just NO WAY I'm going to install a Tokyo Trial on my computer): say you have an old MIDAS application, the one where you could choose between a socket connection, DCOM, etc.
I was wondering about something I can't try for myself (using Berlin and there is just NO WAY I'm going to install a Tokyo Trial on my computer): say you have an old MIDAS application, the one where you could choose between a socket connection, DCOM, etc.
Given that you include MidasLib and obviously not use DCOM, would that compile for Linux?
Has anybody tried that?
Just curious on the outcome...
A
Given that you include MidasLib and obviously not use DCOM, would that compile for Linux?
Has anybody tried that?
Just curious on the outcome...
A
I guess it won't compile for Linux as it used Windows-specific COM API to dispatch method calls.
ReplyDeleteThat is what I think as well, but as long as you use a socket connection and the MidasLib unit, I really don't see why it shouldn't. Sure, you can't use COM, but you can use a client dataset alright in FMX, so it may well work. It's one of those things that may have occurred to them. If instead, as you say, the whole dispatch thing is based off COM then that's another matter. But I wouldn't call that as guaranteed as you seem to be so certain about.
ReplyDeleteI said "I guess" ;-) I imagine the client-side of clientdataset might be usable as an in-memory dataset, including saving/loading data as XML or binary, without the remote provider. But - again - I'm only guessing here. I would expect, as soon as you need Datasnap.Win.SConnect (where TSocketConnection, TWebConnection are) it won't compile for Linux. (I guess)
ReplyDelete"If you can" is the key here :)
ReplyDeleteAndrea Raimondi Well, I've explained why I think you can't. ;-) But if you can, by all means, go ahead and show me, it would surely be interesting!
ReplyDeleteFor interest/what it's worth:
ReplyDeleteWe have an "old" Midas application (in fact still in production) which we've experimentally converted to use HTTP/S using "new" Midas, *ex*cluding Midaslib [not needed!] and with no MConnect or SConnect in the application (but not released to production) some time ago with a view to potentially rolling out a newer version to eliminate the COM dependency etc.
The key point of interest here is that both the "old" and the "new" applications are mostly the same thing, with a minimal set of adaptations to allow the "new" build to talk HTTP/S to a "new" style Datasnap server server with no COM (or socket server) involved.
To keep the changes to a minimum and retain backwards compatibility for the time being, the client code still uses interfaces (where relevant) having their genesis in type libraries etc, and mostly the client code is "unaware" of the changed connectivity, except that "new" version of app uses adapter classes (a custom connection component and a datamodule implementing the required IAppServer and custom interface methods by adapting to new datasnap, in fact using DBX as this conversion was done some time ago. We should probably now change this to use FireDAC but I digress...)
The adaptor classes unit contains only about 300 lines of code and as mentioned contains 2 classes to make this work -- a custom "connection" class (subclass of TCustomRemoteServer) and a standard datamodule class, augmented to implement the IAppServer + descendant interface elements expected by the application.
On the server side obviously a new(er) server was created, again this was refactored from the original COM server such that both the old and the new server still compiles and works to the original type library interfaces, except no type library or com dependencies are used/linked in on the new server, and simultaneously keeping the changes to a minimum. Meanwhile the old server still compiles and works as before.
It's a bit ugly here and there but everything does work, the point being that the new style of client and the new style of server entirely sidesteps COM and theoretically this new client (for windows) should therefore work against a server on non-windows platforms without too much trouble. All of this on Berlin. Caveat being that it is all still entirely Windows so I cannot guarantee that there's not some gotcha or dependency somewhere that I've overlooked. That said we have Tokyo and may look to migrate forward soon so I might be in a position to look into this further. I've not looked into compiling for Linux at all yet.
Edit: Corrected from stating "including Midaslib" to stating "*ex*cluding Midaslib [not needed!]". Also to add: I guess the point is that a similar approach may perhaps suffice for what you're suggesting to do, if you're prepared to make similar changes and are willing to convert to using "new" datasnap HTTP/S connections. (I can't imagine that you'd have a problem with that though?!) Also I'll perhaps post back if we do move to Tokyo soon and try what you've suggested on our codebase, and report back if you want.