Where are the host::Xaction methods implementations?

but I am confused now!

for instance, squid is the host application written by other people, and I can download it with any version from its official website, so how can they write the virgin() method in advance before I write eCAP moule?

what I mean is that the writter of squid maybe has no knowledge about eCAP, he doesn't need to implemente the virgin(), so how to make it?

well, perhaps I understand it.

when I want to use squid as the host application, I must re-compile squid with eCAP lib, and this makes the host application able to implement the virgin() method, and when the start() method is called, the host application has already created the hostx and passed it into our module by the construction function of our Adapter::Xaction.

Am I right?

Yes, more or less. Squid implements the "Host application" part of the eCAP API. To enable eCAP support in Squid, you have to ./configure Squid with --enable-ecap.

well, there are two versions of xaction.h, and I guess one is for the host application, say squid, the other one is for eCAP adapter development

 when I downloaded the libecap-1.0.0 source code, I wondered why there are two versions of xaction, and I wrongly thought adapters would need both of these two versions, but now I know, only the adapter's version is what I need if I want to develope the adapter module, the other one is just for re-compilation with the host application.

is my above guess true?

Yes, more or less. Adapters override and implement methods in classes declared in the libecap::adapter namespace. Host applications override and implement methods in classes declared in the libecap::host namespace. The situation is pretty symmetric with regard to implementing the missing pieces in an adapter and a host application, although the host application has to implement more eCAP stuff while the adapter focuses on the adaptation logic.

The library contains two files named xaction.h, but the full names of those files are different, and the files contain different classes declared in different namespaces.

thanks, but just one more question with regard to what you said as the following:
----------------------------------------------------------------------------------------
The situation is pretty symmetric with regard to implementing the missing pieces in an adapter and a host application, although the host application has to implement more eCAP stuff while the adapter focuses on the adaptation logic.
----------------------------------------------------------------------------------------

If I want to write an adapter, do I still need to write some implementation on the part of the host application?

for instance:

-----------------------------
hostx->virgin().body()
-----------------------------

do I have to implement hostx->virgin(), Message::body()., etc?

No. Adapter writers override and implement methods in classes declared in the libecap::adapter namespace.

Think about it: If you were to alter the host application, your adapter would not work in the [same] host application built by somebody else, defeating the purpose of having a shared API for all host applications and all adapters.

The situation is similar to loadable modules for Linux kernels. If your loadable module implements the right API, it can be loaded into any compliant Linux kernel without you having to modify the kernel itself. In the case of eCAP, a compliant adapter can be loaded in any compliant host application without modifying that host application.

I understand it, thanks a lot.

this question can be closed now, and I will open another new question:)

Thanks Alex Rousskov, that solved my question.