This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-01
Channels
- # admin-announcements (1)
- # beginners (16)
- # boot (22)
- # cider (96)
- # clojure (146)
- # clojure-dev (5)
- # clojure-germany (7)
- # clojure-greece (3)
- # clojure-italy (5)
- # clojure-japan (76)
- # clojure-russia (6)
- # clojure-seattle (1)
- # clojure-sg (1)
- # clojure-uk (19)
- # clojure-ukraine (1)
- # clojurescript (114)
- # code-reviews (11)
- # datomic (42)
- # editors (4)
- # euroclojure (3)
- # jobs (18)
- # ldnclj (59)
- # off-topic (1)
- # om (17)
- # reagent (5)
- # yada (43)
i’m referring to the talk by David Nolen on sending the pull spec to the REST endpoint instead of having it configured statically in the server
the Datomic REST peer deals with this by requiring a POST request for larger query expressions
I don’t it becomes harder.
First, the URL/URI/IRI in general have a (sane) limit of 64k but that’s up to the implementation
Responses to POST requests are perfectly cacheable if you set the respective headers. Additionally conditional requests are supported for POST, too.
well, that’s what apache does.
If you encounter problems you can POST the pull spec to /db
and be redirected to a resource based on a hash of the spec, e.g. /db/f8e3183d38e6c518
the server needs to maintain a short-lived cache for the mapping of the hash to the spec.
technically that’s bad conversational state but it gets it done in most cases
RFC7230 has a section on that
> Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). > However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST’s effective request URI (Section 3.1.4.2).
I need to check how native mobile HTTP clients behave in this case, but for most of them you can configure the caching mechanism pretty well
besides that, are you investigating on that pull spec over http topic now? I had a intense discussion with David on the usefulness of HTTP2 in general and especially server push for serving responses to pull specs.
I want to prove him wrong
well the thing is, it would be nice for the client to be able to specify which data exactly it would receive on a certain screen
sure, I guess that http2’s support for fine grained resources would be improve the caching situation
now we’re using some ad-hoc stuff like ?detail=full or whatever, but you can’t cater for every situation obviously
http2 allows the server to push responses to the client on it’s own.
another thing we’re doing frequently with datomic is ‘change detection’: client opens a long running connection on a certain resource endpoint, specifies which data it is interested in and only receives updates when changes are made in the database and are in scope of the client’s request
yes, david favors a polling loop. the reasons have been left unclear to me unless positive experience of him with that at NYT
with server pus, if you send a pull spec, you could get back a bunch of responses, one for the „result list“ and one for each result. Every response has it’s own cache lifetime and modification date.
if another search gives a similar result list all the common results do not need to be sent again.
but, YMMV and it needs to be tested.
it’s there.
in chrome, netty, jetty, firefox, whatever.
RFC2616 is obsolete
I’ll need to investigate if our stack is ready (nginx as SSL proxy, retrofit on Android, AFNetworking on iOS)
Sounds like quite some work…