This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-09
Channels
- # admin-announcements (9)
- # boot (114)
- # cider (15)
- # cljs-dev (10)
- # clojure (35)
- # clojure-boston (5)
- # clojure-dev (39)
- # clojure-greece (1)
- # clojure-japan (10)
- # clojure-nl (3)
- # clojure-poland (2)
- # clojure-russia (10)
- # clojure-sg (8)
- # clojure-switzerland (1)
- # clojure-uk (34)
- # clojurescript (76)
- # clojurescript-ios (3)
- # clojurewerkz (1)
- # clojurex (9)
- # cursive (3)
- # datomic (1)
- # devcards (137)
- # emacs (5)
- # events (1)
- # hoplon (99)
- # jobs (1)
- # ldnclj (50)
- # off-topic (1)
- # om (3)
- # onyx (10)
- # re-frame (4)
- # reagent (1)
- # ring-swagger (15)
- # yada (35)
hi @mccraigmccraig - the rationale is my reading of https://tools.ietf.org/html/rfc7231#section-4.3.4 but it's a bit ambiguous
yes, i'm definitely planning to support Prefer - you must be an http nerd like me for knowing about that!
Prefer is also very useful for yada's asynchrony: http://tools.ietf.org/html/rfc7240#section-4.1 - I've included 7240 in the release for a while, partly to remind me to implement it
I've been a bit quagmired in implementing async streaming for large request and response bodies
taken me a longer time than I expected, but has ended up being 'the right thing to do'
hey @malcolmsparks i wouldn't have called myself an http nerd, but i did notice the RFC7240 you referenced in the PutMethod and i did rtfm for once
looking forward to async streaming - i have an entirely async application apart from the handlers dealing with http uploads, which is niggling me
@mccraigmccraig: is there a clojure exchange talk in your work? or can't you talk about it
@malcolmsparks: dunno - there's no particular reason i can't talk about it - i hadn't thought about it
when/where is clojure exchange ?
dec 3/4
ah, got it - skillsmatter
having a totally async app is pretty novel
and lots of people are interested in async now
especially what you've been doing with manifold chains
I think there's a talk in manifold - I've been reading manifold.stream and think I finally get why it's called manifold
it's a junction box for all the various async apis out there
I think it's a work of genius to think of doing this, and actually accomplish it too
he's right in his docs when he says that library authors need an abstraction to avoid serving only those in their particular walled garden
I feel like manifold was a good choice for yada
yeah, it's pretty neat - i'm certainly glad i stumbled across it - all the pieces fell into place
(and yada was one of those pieces)
hmm. well doing talks is good for me, though i'm not exactly sure i enjoy doing it
what's the talk you and @thomas are doing ?
i feel the same way about yada's upstream ingredients, lots of things all falling into place
it's a proposal for a joint talk about various ways of writing a rest service using his phonebook example - he's doing a compojure/ring version, I'm showing the same but with yada code
his implementation is very neat and minimal, my code is in examples/phonebook in master, but the PUT implementation forced me down the rabbit hole of thinking about streaming bodies...
I've found a really nice trick of finding boundary strings in bodies, with a nice boyer-moore implementation already written: https://github.com/ikoblik/clj-index
i remember doing a boyer-moore impl about 20 years ago
so the implementation will be both fast and asynchronous (compared to commons file upload that is)
it's circa 1977 i think
I hope clj-index doesn't have any major perf problems, I really don't fancy writing a bm implementation - maybe you can resurrect yours!
iirc it was in C
it's a bit tricky, I have to worry about boundaries straddling byte-buffers
but the bm algo is nice, and given everything is byte buffers, you can run it on a whole byte buffer (which helps, because with bm you have to go 'backwards')