On 02/02/12 16:27, Martynas Jusevicius wrote:
Hey Andy,
may I be so bold as to suggest that Jena should drop its various
methods of HTTP access and use one specialized framework to do that
job?
If it helps but I think that Jena encapsulates network access from the
application which does not deal with the network details. Net code is
just an internal issue to Jena. The networking comes down to some fixed
lines of code - I want to not use java.net but
Maybe I just like to understand what's going on at the network level.
The FileManager (and DataManager is a better name) is managing more than
HTTP connections. It is trying to unify file access, classpath
resources, zip and rename indirections. It is also configurable.
The separation of open a stream and parser that to a suitable parser is
the abraction boundary I found worked for me. By mocking files and
other local resources as "TypedStream" I found I could present a
newtork-ish but minimal way to integrate access.
Both the ideas and the code of Jersey are useful but I when I have
looked at it before it was as part of the find-dispatch framework. And
poking around in file extension, even on the web :-( is necessary. It's
not an ideal world out there.
(The FileManager and some of this code is really, really old - I won't
write it that way now ... but it works.)
What do you think about non-web accesses?
I'd like to move the (used) cache code to the Locator chain as well.
What idea have you had about formats without explicit MIME type like
embedded data?
Since RDF and LinkedData are very much RESTful applications, a RESTful
framework like JAX-RS [1] would be more suitable than low-level
libraries like HTTP Commons etc.
Jersey (main Java implementation of JAX-RS) provides nice classes like
WebResource [2] with uniform HTTP interfaces and builder methods.
Using it, I was able to implement loadModel(filenameOrUri) much more
concisely:
public Model loadModel(String filenameOrURI)
{
ClientConfig config = new DefaultClientConfig();
config.getClasses().add(ModelProvider.class);
return Client.create(config).
resource(filenameOrURI).
header("Accept", getAcceptHeader()).
get(Model.class);
}
ModelProvider [3] abstracts the dirty job of reading Model from
request/writing Model to response and does it behind the scenes.
I was planning to use Jena's intefaces with JAX-RS implementations for
Linked Data access in DataManager [4], but now I can see that it's
much easier and uniform to do the way around.
I'm sure JAX-RS could also be useful in Fuseki etc.
We (Epimorphics) heavily use JAX-RS for ELDA
[http://code.google.com/p/elda/].
But for Fuseki (1) I decided not to use JAX-RS because the dispatch
patterns were too restrictive (they are in the compiled code). The
content handling might have been useful but (2) small-foot print code
already existed and (3) the majority of work isn't in the wiring. Its a
balance - there are useful things but I felt they didn't warrant an
extra dependency.
GPL is not useable in Apache products but CDDL is Category B
http://www.apache.org/legal/3party.html
Andy
Martynas
graphity.org
[1] http://jcp.org/en/jsr/detail?id=311
[2]
http://jersey.java.net/nonav/apidocs/1.5/jersey/com/sun/jersey/api/client/WebResource.html
[3]
https://github.com/Graphity/graphity-analytics/blob/rdf_editor/src/main/java/org/graphity/provider/ModelProvider.java
[4]
https://github.com/Graphity/graphity-analytics/blob/rdf_editor/src/main/java/org/graphity/util/DataManager.java
