Recent

Author Topic: Language and platform independent binary standard for objects (aka COM)  (Read 5543 times)

tk

  • Sr. Member
  • ****
  • Posts: 357
I would like to implement a platform independent shared library (DLL/SO/DYLIB...) which the client can use in the same or similar style as the COM server.
The library should provide many kernel functionality classes of our SW (no GUI except some config. dialogs).
Now on Windows and Linux.

In Delphi on Win this can be quite easily done with COM, but in Lazarus and on another platforms?

What do you use in Lazarus for this?

I've looked at ICE (https://zeroc.com/products/ice) but it does not seem to have FPC support.

Thanks

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #1 on: October 05, 2016, 10:31:01 pm »
The library should provide many kernel functionality classes of our SW (no GUI except some config. dialogs).

Here's the approach I use:

https://macpgmr.github.io/MacXPlatform/PascalDynLibs.html

(1) Always create a header file for your library.

(2) Decide what languages your client will use. In my case, Python and .NET are typically the ones I see requested, although some shops use JVM-based languages. Again, the header file is the first place to start.

(3) Don't put _any_ GUI in your library.

tk

  • Sr. Member
  • ****
  • Posts: 357
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #2 on: October 05, 2016, 11:01:59 pm »
Thank you but it seems that this approach I use already for shared libs where I only export simple functions and types, not whole classes.
This works fine for me in Lazarus, at least under Win/Linux/OSX.

But now I would like to export whole classes or interfaces. So that developers of the client app can use object-oriented idioms. Exactly like the COM does it: http://www.delphisources.ru/pages/faq/master-delphi-7/content/LiB0121.html.

I don't see an example for this in PascalDynLibs.

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #3 on: October 05, 2016, 11:06:28 pm »
See Part 3 for the NDFD library. That's exactly what it does.

Here are the steps:

(1) "Tear down" your app's core functionality into separate functions.

(2) "Build up" (reconstitute) the original class in one or more languages.

That's generally the way it's done in big projects.

Example:

http://gdal.org/

The GDAL library is written primarily in C++, but it provides a C interface and header file (what I used to create Pascal interface), C# wrapper classes, Python wrapper classes, etc.

tk

  • Sr. Member
  • ****
  • Posts: 357
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #4 on: October 05, 2016, 11:36:44 pm »
(1) "Tear down" your app's core functionality into separate functions.

(2) "Build up" (reconstitute) the original class in one or more languages.

This way I even did not consider. Is quite a lot of work (or seems to be, for many classes and their members I have and for different languages), want to avoid that.
VS, Delphi, etc. have TLB importers to create the library headers for different languages from the COM IDL automatically.
Unfortunately works only on Win.
Or do I miss sth?

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #5 on: October 06, 2016, 12:42:15 am »
In today's world, it looks to me like COM is an idea whose time has passed. Unfortunately that means we're back to perhaps the lowest-common denominator, that is, the C header file. However, outside of the Windows world, that's what has always been used.

C++ projects often use SWIG to automate the creation of wrapper classes in other languages from header files (that's what GDAL uses), but Pascal is not supported, although I do see some old work in that area:

http://swig.org

http://wiki.freepascal.org/SWIG

Note that just coming up with one or more other language interfaces to your library is only part of the solution. Here are a few other tips to keep in mind (and sorry if I sound like I'm playing the speaking-from-experience card):

(1) Make sure you "dogfood" your library and its interfaces. Ideally this would be that your mainline app itself uses the library (eg, via a Pascal interface to the library). Why not just compile against the Pascal units as per usual? Well, like unit tests, that's an incomplete way of testing everything, including the library.

In my case I had an auxiliary project that needed the functionality of the code in the library. Instead of just writing additional code in Pascal that used the library's units, I wrote it in Python, just like a client might. Not only did I end up making a lot of improvements to the interfaces, I also improved the Pascal code quite a bit. Something about the shift in perspective from being the producer of the code to the consumer of the code really made a difference in how I saw the code and its interfaces.

(2) Libraries have a way of being used for Web apps, meaning it's critical that they can be parallelized. For example, does your code create any temporary files? How are those files named? Etc.

(3) Check with your clients on this, but I think they generally prefer if your library is single-threaded. That way they can parallelize it if necessary however they want. That's also what I did in my auxiliary project: used Python's Pool to parallelize it across all CPU processors for maximum performance.

avra

  • Hero Member
  • *****
  • Posts: 2261
    • Additional info
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #6 on: October 06, 2016, 09:17:22 am »
You should take a look at some language and os independent solution which can pass proxies like butter. Something like older XML-RPC or newer JSON-RPC. They are both supported in FPC/Laz.

If you decide to take the JSON-RPC path, then you can for example peek at how KODI (XBMC) uses JSON-RPC to publish it's interfaces automatically, so that developers can always easily get up to date interface info. Here are some remote control and query examples how can that all look like: http://kodi.wiki/view/JSON-RPC_API/Examples

Stuff to inspect:
https://en.wikipedia.org/wiki/JSON-RPC
https://en.wikipedia.org/wiki/XML-RPC
http://jbsolucoes.net/ceosmw
https://github.com/graemeg/freepascal/tree/master/packages/fcl-web/src/jsonrpc
http://wiki.freepascal.org/Web_Service_Toolkit
http://wiki.freepascal.org/JSON
http://wiki.freepascal.org/fcl-json

EDIT: Silly me, now I see that you need all this for a library and not for your application. Well, library is not needed at all after you implement json-rpc into your app, so it's up to you.
« Last Edit: October 06, 2016, 09:28:20 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

tk

  • Sr. Member
  • ****
  • Posts: 357
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #7 on: October 06, 2016, 11:30:43 am »
Thank you Phil and Avra for your ideas.

Since the library will only be used as in-process server I think that the swig approach is the closest match. The only problem is the missing support for Pascal but there are tools to convert Pascal interface unit to C++ and vice versa. I must check them out. It will surely need some work (and repetitive work when the interface unit to my library changes) but there should be definitely less work than to write and maintain all the interfaces (now I plan at least C++ and C# support) by hand.

Quote
In today's world, it looks to me like COM is an idea whose time has passed.

That I know but still this is a technology which has IMO wide support in dev tools on Win. And it works. I think for Win users I'll deploy the type library as well.

Quote
Ideally this would be that your mainline app itself uses the library.

Maybe later. Now I plan to export only the very basic features. And it is IMO better to link the library sources directly to the mainline app than calling them through some interface (speed).

Quote
Check with your clients on this, but I think they generally prefer if your library is single-threaded.

Interface is single threaded but the library spawns another threads.

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Language and platform independent binary standard for objects (aka COM)
« Reply #8 on: October 06, 2016, 09:47:30 pm »
And it is IMO better to link the library sources directly to the mainline app than calling them through some interface (speed).

That's what people often think about libraries, but you may find it difficult to demonstrate any difference in performance. With desktop apps, most of the time is spent waiting for relatively slow things (UI, disk, Internet) rather than on the calling of code, or else the app spends much of its time inside methods which are invoked with a single call. With these types of apps, you would need a huge number of calls into the library to make any measurable difference in performance compared to code statically linked into the executable.

If you _are_ able to demonstrate a difference in performance, then you should really be concerned with COM, which is much slower than calling into a dynamic library. In my testing, I was astonished at how much slower a COM server was compared to a library compiled from the same Pascal code. COM must have considerable overhead compared to calling a dynamic library directly.

Certainly there are reasons not to use the library with your mainline app (disruption, new bugs, etc.), but I doubt if performance is one of them.

 

TinyPortal © 2005-2018