Re: [Aperture-devel] Report - 27.10.2006

[Leo S. <leo...@df...>]

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
> Ape...@li...
> 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...@df...
____________________________________________________