Reto Gmür schreef op 8-4-2014 18:23: > Hi Minto > > I think the best solution would be too split TcManager into two: > - One service component exposing TcManager Is the use of this TcManager mandatory? The added value of this manager is being a composite over various providers with the ability to query over multiple providers and add access control. Other than this is see little added value. So if I don't need this why should I be forced to use it? > - One non-service component registering all graphs as individual service This looks like a graph registry to me :-)
Who tells this registry of new or removed graphs? Currently this is integrated in TcManager. But if TcManager is bypassed (which is already possible) the registry is not kept in sync. Do we want to cope with this? If yes, how? Need providers become aware of the Registry? Despite al these question I do like the idea of separating the Registry out of the Manager. > > In your case you would disable the second component. I would be happier if I could just bypass TcManager. It isn't doing anything that helps me. Looking from the TcProvider perspective. Isn't is cleaner if it exposes all its abilities? Depending on the provider this would be one or more of the following WeightedTcProvider, TcProvider and QueryableTcProvider. I will give adding QueryableTcProvider as a service a try. If it works would this change be acceptable? > > Cheers, > Reto > > > On Mon, Apr 7, 2014 at 10:06 PM, Minto van der Sluis <[email protected]> wrote: > >> Hi Folks, >> >> While trying to solve my issues with TcManager (which is solved by now) >> I tried to bypass TcManager altogether. I tried to wire my code directly >> to a TcProvider. Besides the now fixed missing TcManager instance I had >> another reason. >> >> TcManager creates a service for every graph. In my environment this >> could prove to be quite expensive since it a can have a large number of >> graphs (production already has nearly 3000). In bypassing TcManager I >> hoped to prevent this (for me) unneeded dynamic behaviour. >> >> For one bundle I was able to circumvent TcManager by directly wiring it >> to the WeigthedTcProvider. Unfortunately for another bundle this was not >> enough. That particular bundle also likes to execute queries. Which is >> only possible through the QueryableTcProvider. My initial thought was to >> use a typecast. But is appeared the the WeightedTcPovider was not >> implementing it, even though the sources (TDB) said it did. >> >> A debug session revealed that because I was using Blueprint a proxy >> object was created. Now my only option is to drop Blueprint unless ... >> >> Shouldn't TcProvider services that also implement QueryableTcProvider >> expose this interface as a service as well? Like this I could wire my >> bundle to the queryable interface instead. >> >> Regards, >> >> Minto >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
