On 1/22/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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] Pete, Jean-Sebastien, thanks, I think I understand the issue now. I'm
happy with the intermediate for what I'm doing at the moment. If a proxy is absolutely required for use in C++, i.e. you are not using some dynamic invocation based on direct access to the "operation" structure, then I guess it could either be generated into a component DLL (don't have one for PHP at the moment but we could) in the off chance that a C++ component will want to call it or into a special DLL that collects all the scripting C++ proxies together. Can't we infer what the DLL will be called in this case as the DLL should be something generated automatically by the systems. In the case that we rely on annotations in the script to define the interface we also need a feasible mechanism whereby C++ proxies can be generated in the absence of compile time ".h" information. We could, of course, extend scagen to scan the script for the information. This extra proxy generation and compile step feels at odds with the way people write scripts so this certainly needs some deeper though. Regards Simon
