Pete Robbins wrote:
> On 22/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>> On 1/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>> >
>> > Simon,
>> >
>> > this code is in the extension that handles C++ components so we
expect
>> the
>> > implementation to be C++. This is not the "default" proxy. This
code
>> will
>> > be
>> > invoked because the definition of the component is an
>> implementation.cpp
>> .
>> > There is similar code in e.g. the ruby RubyServiceProxy that will
>> handle
>> > implementation.rb.
>> >
>> > Hope this helps.
>> >
>> > Cheers,
>> >
>> >
>> > On 21/01/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> > >
>> > > The default C++ proxy currently seems to assume that its always
>> trying
>> > to
>> > > talk to a C++ service. Line 104 of CPPServiceProxy looks like
>> > >
>> > > // If we got here we have a CPP implementation
>> > > CPPImplementation* impl = (CPPImplementation
>> > > *)componentType;
>> > >
>> > > Did I understand this correctly? If so why is this the case?
>> > >
>> > > Regards
>> > >
>> > > Simon
>> > >
>> > >
>> >
>> >
>> > --
>> > Pete
>> >
>> > Thanks for the reply Pete. I'm still not sure I understand this.
>> What is
>> the role of the CPPServiceProxy intended to be. I would guess, just
>> going
>> on
>> the name, that it is intended to be the CPP proxy for services as
>> opposed
>> to
>> a proxy for CPP services. But I guess I'm missing something.
>>
>> The reason I'm asking the question is that I wanted to set up a local
>> CPP
>> client for my PHP component. I couldn't get SCA to do this directly,
>> i.e.
>>
>> CPP Client --> PHP Component
>>
>> I had to put a CPP component in the way to make it work
>>
>> CPP Client --> CPP Component --> PHP Component
>>
>> Which struck me as a little strange. I expect my error lies in the
way
>> that
>> I get hold of the context, locate the service or something else.
Clearly
>> there is a proxy somewhere that is able to talk to my PHP component
from
>> CPP. How do I get an instance of this one in the CPP client?
>>
>> Regards
>>
>> Simon
>>
>>
> Ah. I see. The client interface using CompositeContext is not
great. It
> feels to me like a hack to allow non-SCA code to be logically part
of a
> composite. It is only for accessing a C++ component from a client.
For a
> component implementation the proxies are generated for each reference
and
> wrappers are generated for each service (using scagen) and are
> compiled in
> to the component implementation. For a c++ client this is not possible
> so a
> proxy is generated for each service and this becomes part of the
> component
> implementation. This is why the client has to get a C++ proxy from the
> component implementation... which means it has to be a C++
implementation
> first!
>
> Maybe we can re-think this and find a way to return a service proxy
for
a
> non-C++ component via CompositeContext (the proxy itself will still
> have to
> be a generate C++ proxy and we do not want to have to link this
with the
> client code so where will it live?)
>
> Something to think about but for now you will have to have you CPP
> Component
> as the entry point from the CPP client.
>
> Cheers,
>
Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++
component implementation is easy, but the real issue is that the SCA C++
C&I spec does not define an attribute to specify which DLL contains the
(generated) C++ proxy outside of of a <implementation.cpp>, which you
don't have when your component is not written in C++.
I suggest to raise an SCA spec issue for this, and in the meantime,
package these proxies in a library with a name derived from the name of
the composite or the name of the target component, or as Pete suggested
continue to use an intermediate C++ component as an entry point from the
C++ client.
--
Jean-Sebastien
