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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
