[fpc-pascal] Best way to transfer data between applications?

[Ewald]

On 10/30/2012 02:34 PM, $B0u>l(B $BG50!(B wrote:
> Right, and I am talking about relatively small amounts of data, not movies or something.  The reason I thought of SHM is that there would be no need to decode the structure into a string and re-encode it, etc.  Instead, the application could somehow pass a message and a pointer.  The receiving application then takes over management of that record (or whatever), and the sending application forgets about it (and allocates a new one next time it needs to send something).  
This wouldn't work. You cannot pass a pointer to process A that
references memory of process B. You would receive signal 11 (SIGSEGV).
You could of course copy the block of memory (the object you're trying
to transfer) into shared memory, which you then can access from both
programs, but then I do not see the use of a message with a pointer
(just start the object at offset 0 in the shared memory block).

Either way, this approach wouldn't be `safe`, as any pointer contained
into the object/record/<whatever you call it> also needs te be
re-allocated in the shared memory block. Thus strings and dynamic arrays
would provide for quite a royal pain in the arse to `share` them.

Encoding the object solves this problem. This does not mean that the
data cannot be in binary form however (-> no need for IntToStr and vice
versa!). All integers/floats can still be stored in identical the same
way (i.e. 1/2/4/8 bytes fixed length), and need not be encoded/decoded
in any way, they just need to be copied over from the buffer to the
appropriate location. Strings can easlly be stored as an integer (the
length field), followed by the data of the string itself; just as
dynamic arrays.

Thus if you have a class which contains a number and a string, you would
encode it something like this (think as if you're saving to a file, but
do not optimize for size):
<type:fixed length (say, one byte?)><integer from class: 4 bytes for
objfpc><length field of string: also 4 bytes, could also be 2 if the
strings aren't longer than 65535 chars><data in the string>

The type field is obviously needed for constructing the right class.
Note that this type cannot be a `class of ....` type, as this is in
essence also a pointer (to the VMT if I recall correctly). Then, as
Jorge mentioned you only need to provide a neat little factory that
`converts` these buffers to classes with which you can just continue in
the usual OOP way.

Hope this helps.

-- 
Ewald

Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime.