Hi guys

Es begab sich aber da Christiaan Fluit zur rechten Zeit 30.10.2006 11:44 folgendes schrieb:
The RDF2GoRDFContainer itself. If the user doesn't provide a model - it 
creates a default ModelImplSesame model. I did some searching around the 
code. The only place within core architecture classes those constructors 
are used is the RDF2GoRDFContainer factory. The factory itself is used 
in other parts of the code but no class creates it. If removing this 
dependency is a concern, I would suggest a following solution.
    

We are not using this factory in Aduna code, I'm not sure about others.

The whole idea about all those factories and registries everywhere is to 
support a dynamic system based on e.g. OSGi where there are as little 
assumptions as possible about which implementation classes are used, in 
which order things are initialized and even make runtime changes to the 
setup possible.

As we still make little use of this architecture, perhaps remove it for 
now and introduce a better version as soon as we fully know/agree on 
what "better" means?
  
About the OSGI thing:

one of the next tasks on DFKI side will be to wrap Aperture into a Nepomuk interface for datawrappers,
and to bundle it as OSGI service using the Eclipse plugin concept, with Bundelactivators, etc.
There will also be a service then running, with configuration etc.

Anyone has experience how to handle configuration the "right way" in OSGI?

I am not concerned about the factories, but more on:
A) where to store config values (file, database, config file inside the bundle?)
B) how to change config values (through interface, is there a "configuration" bundle?)
C) how to make a gui that uses B to change A
D) how to make an activator that reads A, perhaps through B?
E) or is it all dependent on a "service" bundle, that wrapps another bundle and provides A,B,C,D for application environment X where it runs. For example, one for Nepomuk, one for Autofocus

greetings
Leo


  
1. Have RDF2GoRDFContainer accept a Model from outside. Don't provide 
any default implementation.

2. Ask Benjamin to create a ModelImplSesameFactory. (I'm actually 
surprised it isn't there).

3. Create a constructor for RDF2GoRDFContainerFactory that accepts an 
instance of the ModelFactory interface. (it is possible since as I said 
no aperture class creates instances of RDFContainerFactory, and the 
DEFAULT_FACTORY static field is never used in aperture).

4. Use the ModelFactory in newInstance and  and getRDFContainer

5. Remove the DEFAULT_FACTORY field.
    

The typical OSGi-like setup that we use is to let the factory (in this 
case the RDF2GORDFContainerFactory) have all configuration info stored 
in its attributes. It gets this info through set methods that are 
invoked by whoever creates these factories (static code, an OSGi 
BundleActivator, some configuration file setup mechanism, etc).

This way the invocation of the factory's get/createNew/whatever method 
is often parameterless. This ensures that future API changes have as few 
consequences as possible and that configuration code needed by a 
specific factory are only reflected by the set/get methods of that 
factory, not by the artifact-producing methods.

  
Leo is right that a malformed URI is usually an indication of a bug on 
our side that should be found and removed.
    

I'm comfortable with URI checking as long as it's optional. With this I 
don't mean that it should depend on a log level whether checks are done 
or not, but that the API should be constructed in such a way that a 
developer can choose whether to use a safe and sound approach or play it 
dirty. A method to explicitly check URIs is an example of such an 
approach, as is for example org.openrdf.model's approach where you can 
easily introduce your own URI implementation transparently, that does as 
much or as little checking as you want.

  > RepositoryAccessData - replaced by ModelAccessData
  
Since rdf2go doesn't support contexts directly it would be up to the 
user of ModelAccessData, to provide a model implementation that would 
use an appropriate context (if necessary)
    

Perhaps leave this class out altogether and reserve some time in the 
future to revisit the AccessData API altogether?

Given recent work on the crawler implementations I really had the 
feeling that we would benefit from being able to use RDF to store access 
data. Of course AccessData can also have a getModel method but I think 
we should consider whether we really need an AccessData on top of a
model or instead give it such a model directly. IMO AccessData does not 
provide an added value over an RDF Model in the way RDFContainer does.


All in all: good work!

Chris
--

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Aperture-devel mailing list
Aperture-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aperture-devel
  


-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 
DFKI GmbH
P.O. Box 2080          Fon:   +49 631 205-3503
67608 Kaiserslautern   Fax:   +49 631 205-3472
Germany                Mail:  leo.sauermann@dfki.de
____________________________________________________