Markus, As we've identified in previous messages, the XDI4J implementation uses singleton classes for parsing, making it unusable performance-wise in anything other than single user mode (using it on a server synchronizes/sequentializes every parse operation).
Regards, Michael McIntosh VP Development Azigo From: [email protected] [mailto:[email protected]] On Behalf Of Markus Sabadello Sent: Friday, May 28, 2010 6:38 AM To: Higgins (Trust Framework) Project developer discussions Subject: Re: [higgins-dev] Sub-contexts The IdAS-XDI-Mapping is documented here: http://wiki.eclipse.org/IdAS_XDI_Mapping In theory, the Java XDI CP, the Attribute Service, and the C++ XDI CP should all implement that mapping, however - the wiki page itself may be a bit outdated in a few details - the Java XDI CP (higgins.idas.cp.xdi) implements an older version of the mapping and is therefore not ready for use. I don't really have an overview of what's needed to make it work For a native XDI store, I believe XDI4j's BDB implementation has good performance, but I haven't tested it or compared to other options. Markus On Fri, May 28, 2010 at 11:19 AM, Joseph Boyle <[email protected]<mailto:[email protected]>> wrote: I talked a little more about the backend question with Mike today. For 4. the only XDI native store I know of is Markus's. It has a context provider higgins.idas.cp.xdi but Mike was not sure if this was finished and working. From the XDI folks perspective, of course using an XDI store would be ideal. Markus, do you think it is ready? For 3. (or 2.) writing a context provider could be a joint effort among Azigo, the 3rd party DB vendor, and others like me. On the other hand, to do performance testing of Higgins with a new DB, there should be a benchmark or stress testing app, and Azigo would be best placed to specify and write the benchmark, which I'm guessing would not be hard. Mike said that we would not expect performance problems for another year or so when bigger deployments are expected. Putting a small amount of work into evaluating databases now might save much more pain later. Perhaps this could even be presented as a distinct project - for example I heard Marc Davis asking if there has been performance testing. The DB vendors might be persuaded to help with the integration work, and then would have the next year to work on any performance problems themselves. Mike said that our current challenge right now is defining API to support adding metadata to sub-contexts, not performance, so having someone else do performance work would be an advantage. I asked Mike what features we should specify as necessary or desirable in a graph database. He suggested we need to be able to attach arbitrary attributes to sub-contexts (subset of attributes from a context) but that I post to the list as Paul, Sergey and Vitaliy could respond. Some of the graph databases offer features like multiple traversal that may be higher level than can be expressed by the Context Provider API. If we want to make use of any of these features, of course the sooner we know about them, the better. Also some of the graph databases claim to provide distributed storage and to try to optimize access across that distributed storage; this could also be very useful for large scale deployment, but needs to be tested in practice. On May 27, 2010, at 7:17 AM, Paul Trevithick wrote: > Thanks for the pointers Joe. > > On May 26, 2010, at 8:37 PM, Joseph Boyle wrote: > >> I continue to hear of more graph databases - just saw >> http://www.infinitegraph.com/ today. I also know of >> http://www.kobrix.com/hgdb.jsp and >> http://www.dekorte.com/projects/opensource/vertexdb/ . >> >> There's also a list at http://en.wikipedia.org/wiki/Graph_database >> >> On May 25, 2010, at 4:02 PM, Paul Trevithick wrote: >> >>> Options: >>> 1. Get on the NG4Jena mailing list and ask for advice [We should do >>> this no matter what] >>> 2. See if there are alternative open source quad stores with better >>> performance/scalability >>> 3. Explore non-relational open source graph data bases (e.g. Infogrid, >>> Neo4j, etc.) >>> 4. Use an XDI native store >> >> _______________________________________________ >> higgins-dev mailing list >> [email protected]<mailto:[email protected]> >> https://dev.eclipse.org/mailman/listinfo/higgins-dev > > _______________________________________________ > higgins-dev mailing list > [email protected]<mailto:[email protected]> > https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
