Rob,
Go for it! It's a good feature to have as result sets can be very
large, as can models and this wil work nicely with streamed triples as
results.
I do need to do the release of Fuseki because I feel bad at pointing
point to snapshots all the time but a few days is fine. I'll be doing
TDB and Fuseki separately so TDB, vote cycle, release, then, if we are
all agreed on a Fuseki release.
Question:
When is gzip'ing beneficial? On a local network, it might not be - I've
assumed (without up-to-date facts) that the gzip costs are more time
than xfer of the uncompressed bytes.
So would this be on by default in the client? Maybe it should, maybe it
shouldn't.
Have you found any good links that describe the experience of using
gzip'ed streams elsewhere?
Andy
On 03/02/12 19:44, Robert Vesse wrote:
Yes I basically just added GzipFilter to some of the servlets
Rob
On Feb 3, 2012, at 10:23 AM, Stephen Allen wrote:
Hi Rob,
Just a quick question. Are you implementing this with a Servlet
Filter? That's what I've done successfully in the past to add GZip
support to Joseki with Jetty [1] (also created one to perform XSL
transformations on the server instead of the browser).
-Stephen
[1]
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/servlets/GzipFilter.html
On Fri, Feb 3, 2012 at 9:38 AM, Robert Vesse<[email protected]> wrote:
Hey
I know the release process is moving along so I wanted to check whether there
was a deadline for patches for inclusion in the Fuseki 0.2.1 release?
I've been working on a patch the last couple of days which enables GZip support
so clients can use Accept-Encoding: gzip and Fuseki will automatically gzip the
responses if appropriate. I have some more testing to do on this and some
related patches for ARQ which enable remote SPARQL execution to use GZip and
Deflate encoded results but I hope to submit this patch in the next few days.
Cheers,
Rob
