On Wed, Apr 9, 2014 at 1:27 AM, Minto van der Sluis <[email protected]> wrote:
> 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 clerezza bylaws mandate this in § 132. > 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? > Using TcManager shouldn't add a big overhead and adds the possibility to add virtual TcProvider. But yes, if things are well designed you can use a TcProvider directly. > > - 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? > Good points. Maybe we should add the possibility to add listeners to a TcProvider. > > 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? > I see no problem in exposing this additional interface. Cheers, Reto > > > > 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 > >
