Mark general purpose TcProvider

[Reto Gmür <re...@apache.org>]

I run into a  problem with TcManager being available as a service but not
able to create (m)graphs as there was no suitable TcProvider yet. In the
tdb.launcher this is solved assigning startlevels that make sure that
TcManager starts after the relevant TcProvider.

As an alternative to these startlevels approach I was thinking about
marking TcProviders as "general purpose" so that TcManager could depend on
having at least on general purpose TcProvider. General purpose TcProviders
would be the one allowing to create any (m)graph, like tdb, irtuoso,
sesame. Non General purpose are the one providing a fixes set of graphs or
a reduced namespace for creating graphs (e.g. FileTcProvider).


Cheers,
Reto

Re: Mark general purpose TcProvider

[Reto Gmür <re...@apache.org>]

On Sat, Mar 1, 2014 at 11:00 AM, Reto Gmür <re...@apache.org> wrote:

> I run into a  problem with TcManager being available as a service but not
> able to create (m)graphs as there was no suitable TcProvider yet. In the
> tdb.launcher this is solved assigning startlevels that make sure that
> TcManager starts after the relevant TcProvider.
>
> As an alternative to these startlevels approach I was thinking about
> marking TcProviders as "general purpose" so that TcManager could depend on
> having at least on general purpose TcProvider. General purpose TcProviders
> would be the one allowing to create any (m)graph, like tdb, irtuoso,
> sesame. Non General purpose are the one providing a fixes set of graphs or
> a reduced namespace for creating graphs (e.g. FileTcProvider).
>

Just noticed SimpleTcProvider. This is a general purpose one according to
the definition above. Yet one usually want to store graphs persistently. If
the contentgraph gets created in SimpleTcProvider because of the loading
timing one loses all data on restart. So I think we we should make sure
rdf.simple.storage is not part of our launchers.


Reto