clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Gmür <r...@wymiwyg.com>
Subject Re: QueryableTcProvider is not exposed as a service.
Date Wed, 09 Apr 2014 22:56:52 GMT
On Wed, Apr 9, 2014 at 1:27 AM, Minto van der Sluis <minto@xup.nl> 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 <minto@xup.nl>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message