I remember you mentioning this earlier and was thinking about this (almost) all day yesterday. For this one project I'm constantly refreshing data in Stardog with data from some other 3rd party apps. I have to tediously keep checking for changes and deletions. Rather than do a huge bulk delete/insert of chunks of data, I do a lot of small reads & writes from & to Stardog -- mostly because this seemed the best way to keep the database running smoothly for the front end that is reading and visualizing the data. So more efficient small transactions would be helpful for me. I've been wondering how much effort it'd take to update dotNetRDF to use SNARL.
But right now I'm running Stardog on the same server as the front-end, so there's no network bottlenecks to worry about. And I can do a full sync to two external data sources that generate about 40k of triples in 6 minutes, which is acceptable right now. I may already be at the point where the limiting factor is the external sources, not Stardog.
On Thursday, July 5, 2012 9:34:06 AM UTC-4, Kendall wrote:
FWIW, the smaller the payload, the bigger SNARL's speed advantage over HTTP. This may or may not matter; and it's certainly easier to implement an HTTP client for Stardog's HTTP API than to dive into ProtocolBuffers.