Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <5344F678.2080904@xup.nl>
Date: Wed, 09 Apr 2014 09:27:52 +0200
From: Minto van der Sluis <minto@xup.nl>
Organization: Xup BV
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dev@clerezza.apache.org
Subject: Re: QueryableTcProvider is not exposed as a service.
References: <5343055A.50105@xup.nl>
 <CALvhUEU3NOi6VAUz+0u1Q400SrZJqVDaj_Rkmmv9JPTozuZO3w@mail.gmail.com>
In-Reply-To: 
 <CALvhUEU3NOi6VAUz+0u1Q400SrZJqVDaj_Rkmmv9JPTozuZO3w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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 <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