Reto Gmür schreef op 8-4-2014 18:26: > On Tue, Apr 8, 2014 at 8:56 AM, Minto van der Sluis <[email protected]> wrote: > >> Reto Gmür schreef op 7-4-2014 22:53: >>> On Mon, Apr 7, 2014 at 10:30 PM, Minto van der Sluis <[email protected]> >> 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
