Simple solution :

Use TSimpleIPC components + my own RTTIObjects unit.

All messages must be descendants of TRTTIObject. (You can use
TPersistent, but i believe my unit is neater for this specific task).

Well, using only standard components i believe you should use
TSimpleIPC components + TPersistent classes

All you need is a way to stream the TPersistent into a string or
stream then pass that resulting string/stream to the simple ipc
components.

That will do what you are asking, without much fuss...

2012/10/30 印場 乃亜 <shir...@galapagossoftware.com>:
> Hi,
>
> I read about MSGPACK before, but it seems to be a binary version of JSON, 
> right?
> I actually don't care about the protocol much (and since it's local, Binary 
> vs. text wouldn't make a lot of difference in transfer speed - though using 
> FPC  native data structures would be faster since they wouldn't have to be 
> converted to an external format).
>
> The problem isn't just the transfer format, but the whole process.
>
> For example, I want to have something like the unix message (Signal) system 
> that allows me to send not just an Integer, but any random data.
>
> For example, let's say I have a daemon running that receives chat messages 
> (or something) and then it wants to send the data to the GUI, so it would 
> call something like:
>
> SendDataToApplication(Gui_App, ChatDataRecord);
>
> Obviously, I could manually encode that data into JSON or CSV (or msgpack) 
> and manually send it to the other app by IPC and manually decode it on the 
> other side.  What I want is some system that will know that the incoming 
> message is of type TCharDataRecord (or whatever) and automatically let me use 
> that type (and not forced typecasting with pointers, etc. - but properly).  
> Obviously there would be limitations to any solution - for example, I would 
> have to have the same types available on both sides, etc.
>
> I will take a look at msgpack, though, to make sure it can't do the above, 
> though.  What little JSON I have done in FPC, I have done manually thus far, 
> so perhaps I need to learn the capabilities of the real units before asking 
> more.
>
> Mainly my question was asking if there is a "standard" way to do this, since 
> it seems like a common thing to need to do.
>
>  Thank you,
>     Noah Silva
>
> On 2012/10/29, at 18:00, ik <ido...@gmail.com> wrote:
>
>> On Mon, Oct 29, 2012 at 5:52 AM, 印場 乃亜 <shir...@galapagossoftware.com> wrote:
>>> Greetings,
>>>
>>> I am familiar with the basic underlying methods available for transferring 
>>> data between processes on Windows and Unix, i.e. Pipes, Shared memory, and 
>>> TCP/IP - but what I am not familiar with is any higher level functionality 
>>> that may be available on FPC.
>>>
>>> As an example:  I have one application with a daemon that uses the IPC 
>>> component to write to a file in CSV format, and then the user application 
>>> reads this (GPS location) data via IPC.  Then I have to re-convert this 
>>> string data into a series of floating point values manually, though.  The 
>>> IPC component doesn't seem to be reliable on all platforms either (it 
>>> sometimes blocks on OS X, and at least the debug client doesn't seem to 
>>> work at all on Windows 7).
>>>
>>> Another disadvantage is that the sequence of launching the applications 
>>> matters, and what's more, it seems there can only be one "client" per 
>>> "server" in many cases.
>>>
>>> More to the point, if I want to pass around structures, records, 
>>> etc.between processes - what is the best day?  For example, Javascript uses 
>>> JSON.  I know there are JSON libraries and various other libraries for 
>>> Pascal - but I don't know what is the most standard way.  (I think this 
>>> kind of marshalling/unmarshalling may be more standard in Java and C#, but 
>>> I don't know the "normal" way in Delphi/FPC).
>>>
>>> I would prefer to use built-in functionality, rather than learn yet another 
>>> library - and if learning a library, I would prefer to use one with lots of 
>>> users that is actively maintained.  Likewise, I would prefer to actually 
>>> "pass" the data, rather than just pass a pointer to it.  I plan to have the 
>>> processes run on the same machine, so I don't need a solution that works 
>>> with networking, though that would be fine, of course.
>>>
>>> Along the same lines, a convenient way to call functions/procedures with 
>>> parameters from the "other" process would be greatly appreciated.  (i.e. 
>>> something like RPC that handles OOP).
>>
>> I'm writing at the moment support for msgpack (http://msgpack.org/) in
>> plain FPC (object pascal style):
>> https://github.com/ik5/fp-msgpack
>>
>> I will also implement the rpc version.
>>
>> MsgPack allow you to take data, including JSON and convert it into
>> bytes that represent the data.
>> It contain smaller version of the same way that JSON does it for example.
>>
>>
>>>
>>> Thank you,
>>>     Noah Silva
>>>
>>>
>>> _______________________________________________
>>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>> _______________________________________________
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to