Right... for specific binding(s) there might be a co-located optimization (whereas maybe other bindings require some sort of normalized data format). However the question of where the target service is co-located or not is clearly not a binding-specific question to answer.
As far as optimizations in the non-co-located case.... this brings to mind the separate but related note which I also mentioned in TUSCANY-1678: that we should be able to turn off the PBVInterceptor in the case where a copy had already been done... and this would be such a case. Scott On Jan 23, 2008 12:51 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > Hi Scott > > snip... > > > A key piece of the puzzle would be the ability to query what's "on the > > other side of the binding". For example, I might have a binding > > impl with a co-located (same-JVM) optimized path in which I don't want > > to do a transform if the service impl uses the same DB as the client. > > But I'll need to query some metadata in order to know what the DB > > of the service impl is (as well as maybe other info like what > > classloader is uses and if it's the same or a parent of mine or not) > > > > > > I guess that takes us to the info stored along with the domain/node .. > > but I'm not too familiar with that code. > > > > An interesting thought. In the specific example you give of the > co-located reference and service I would imagine a specific node/runtime > could consider this optimization. In the more general case where the service > might be remote from the reference then I guess the Domain would have to > coordinate this or at least make the information available as you say . It > doesn't at the moment of course. Do you have specific scenarios in the > remote case where optimizations would be appropriate? > > Regards > > Simon > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
