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: <53445753.3030407@xup.nl>
Date: Tue, 08 Apr 2014 22:08:51 +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: A bold idea
References: <53430AE7.2000709@xup.nl>
	<CALvhUEWJ47UbqO1iPq2cY+WKtA6OJavwJKiv+dixYqBq3R1h4A@mail.gmail.com>
	<53439DB4.70809@xup.nl>
 <CALvhUEVrRtn-gLTP4x+uhvULRb7-fXT232re1tESVi94s4P5sA@mail.gmail.com>
In-Reply-To: 
 <CALvhUEVrRtn-gLTP4x+uhvULRb7-fXT232re1tESVi94s4P5sA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Reto Gm�r schreef op 8-4-2014 18:26:
> On Tue, Apr 8, 2014 at 8:56 AM, Minto van der Sluis <minto@xup.nl> wrote:
>
>> Reto Gm�r schreef op 7-4-2014 22:53:
>>> On Mon, Apr 7, 2014 at 10:30 PM, Minto van der Sluis <minto@xup.nl>
>> wrote:
>>>> Hi folks,
>>>>
>>>> Lately I had a bold idea, but first let me explain how I got there.
>>>>
>>>> In Clerezza bundles that implement TcProvider are mostly restricted to a
>>>> single instance due to the bundle's configuration. The only viable
>>>> construct I see (please correct me If I am wrong here) to create
>>>> multiple instances is to create another bundle that expose the same
>>>> service with a different configuration. This seems like quite a hassle
>>>> to me. What if ....
>>>>
>>> I don't see the problem having multiple configurations in one bundle. In
>>> Stanbol for example the defaultconfiguration bundle configures several
>>> services with the same implementation cclass:
>>>
>>>
>> http://svn.apache.org/viewvc/stanbol/trunk/data/defaultconfig/src/main/resources/config/
>> Where exactly in there is the configuration for one or more providers? I
>> fail to see it. I see lots of config, but none specifies where a
>> provider is to store the actual data (like disk location or endpoints)
>>
> Well, couldn't there be a service property set for that purpose?
>
>
>
>>>> What if TcProviders were more like JDBC providers. Then a single
>>>> provider could more easily be instantiated multiple times comparable to
>>>> JDBC datasources. This could even be done dynamically like [1].
>>>>
>>> Could you tell more how this would look like. Would a Graph be a
>> datasource
>>> or a TcProvider? Would we still have arbitary URIs to address Graph?
>> It's just a bold idea and I haven't figured it out yet complete. But I
>> could image that the DataSource allows to create a connection just like
>> in JDBC. This connection object looks probably closest to the current
>> Clerezza TcProvider.
>>
>> For the second question. Why not?
>>
> It's a long time since I've been using JDBC. And had some jdbc pseudo URIS
> somewhere in my mind....
The jdbc uri's are to connect to providers. These providers give access
graphs still with full URI support.

Anyway it was just a wild idea. I wanted to figure out if there are
major objections against such a scenario.
>
> Cheers,
> Reto
>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541