Hi. Michael, I agree with you for the separation of concerns.
The new design use :
"TAbstractTransport" for the transport layer
( specialization could be HTTP, TCP, ...).
"TAbstractFormater" for the serialization of content
( specialization could be SOAP, XML-RPC, custom binary, ...)
"TAbstractCallMaker" to make the call over the transport
( specialization could be SOAP handler, XML-RPC handler,
custom binary handler, ...)
"TAbstractFormater" and "TAbstractCallMaker" has to be synchronized.
There are 2 registries :
The first one to register transport
The second for message handling.
The toolkit interface has been unified in one unit, which you'll find
has attached file.
Inoussa O.
2006/4/24, Michael Van Canneyt <[EMAIL PROTECTED]>:
On Mon, 24 Apr 2006, Inoussa OUEDRAOGO wrote:
>> Does it overlap regarding functionality?
>
> This package have a different goal; The primary goal is to expose
> services as normal fpc interfaces by providing a proxy implementation
> as Delphi does; please take a look at the doc file.
It is interesting to see this, as it is complementary to the fpRPC
mechanism.
Before I would include it in the FCL, there is additional work:
1. Use a plug-in architecture for the transport layer.
Hardcoded transport using Indy is good for a first version, but
an RPC mechanism should be independent of the transport layer.
2. Use a messaging system which is not necessarily XML based.
XML introduces serious overhead.
3. The creation of SOAP services should be included as well.
(like xml-RPC)
In my opinion, an RPC mechanism needs 3 parts:
- Interface description and generation. You have this in one
direction, and fpRPC also has this in the other direction.
- Message handling. Message can be XML, SOAP, binary, whatever.
XML is portable, but slow.
- Transport handling. Transport can be HTTP (using Indy, Lcl, Synapse,
whatever) or Windows WM_COPY transport, local socket, named pipes,
shared memory: whatever. This is independent of the message.
These 2 last parts are separate from each other and from the first part:
it should be possible, at any stage, to replace one part with another.
Your implementation definitely has the potential to do this. If you have
ideas of how to achieve what I describe here, I'll be glad to discuss an
implementation with you !
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
service_intf.pas.tar.gz
Description: GNU Zip compressed data
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
