liberator

malcolmsparks 2015-07-16T20:48:23.000035Z

I've been working on a new conneg namespace for yada, but in such a way it could be used by Liberator, as @ordnungswidrig and I discussed at euroclojure this year

malcolmsparks 2015-07-16T20:49:02.000038Z

the idea is that you specify a vector of maps, each map defines a 'cross-product' of possible representations

malcolmsparks 2015-07-16T20:49:24.000039Z

that way, you could offer Japanese in Shift_JIS, but only on GETs

malcolmsparks 2015-07-16T20:50:08.000040Z

while restricting English to UTF-8 and US-ASCII, unless there's an error, when you can renegotiate and provide errors in html, or json

malcolmsparks 2015-07-16T20:50:28.000041Z

i.e. the sort of flexibility Apache has

malcolmsparks 2015-07-16T20:51:10.000042Z

I'd be very interested in any initial impressions and other feedback

malcolmsparks 2015-07-16T20:51:36.000043Z

I haven't done langs or transfer encodings yet, but they're very possible in this design

malcolmsparks 2015-07-16T20:52:36.000044Z

also, representation options are properly sorted in priority order as per the HTTP specs, as per the old TODO in the original conneg.clj

malcolmsparks 2015-07-16T20:53:58.000045Z

I'm happy to spin it off into its own project if necessary, or redo it totally, but I needed something with more features than conneg.clj was providing

ordnungswidrig 2015-07-16T21:02:24.000046Z

I thought about doing the same. The backside is that liberator is bound to an implementation model that does step-by-step negotiation on media-type, language, charset and encoding. I’ve started refactoring liberator’s conneg namespace and still have not found a way to provide a combined conneg as you described while still being backward compatible.