it appears so

https://tools.ietf.org/html/rfc7232#section-3.1

"If the field-value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation."

There are times when you want to state which representations are available up-front, there are other times when this can only be determined at request time. For example, the request may have a path parameter indicating the file in a directory, and you want to look at the file suffix to determine the available representations.

The problem of me is whether to add a 'ctx' parameter to the (representations [_]) protocol. If I do, then I make it hard for tools to determine say the media-type of a resource without sending a request 'tracer bullet' through - I want to avoid doing that, it's hacky

My current thinking is to pack together many of the protocols into 2 - both called 'resource-properties' - one with the request context, one without. (resource-properties [] [ ctx]) simply returns a map with :parameters, :representations, :last-modified, :exists?, :allowed-methods, etc.. I think that's more Clojurish than using a protocol for each individual property, it's more data-centric, and it allows some properties to be returned in either/both maps.

@malcolmsparks: i upgraded to "1.0.0-20150823.133532-5" (from "1.0.0-20150816.005601-4") and my resources are hanging after the resource function returns an unrealised Deferred... derefing the Deferred before returning it stops the hang

i.e. this hangs https://www.refheap.com/108747 , but if i uncomment line 20 it works

hmm. that's odd. You are certainly meant to be able to return a deferred from the function. The yada.methods code calls your GET in a manifold chain. What is r exactly?

Perhaps r is not recognised (by manifold) as a deferred, even though you can deref it. I'm not familiar with your monads

r is a vanilla Deferred... the monad isn't doing anything clever

Manifold doesn't recognise all things as deferred - it recognises it's own futures/promises and the clojure core ones

you mean it's a vanilla promise (or future) ?

what do you mean by vanilla in this case?

does m/return return a deferred?

yes, it's a manifold Deferred, as produced by manifold.deferred/chain

https://github.com/employeerepublic/defurred/blob/master/src/cats/monad/deferred.clj#L48

it's the cats monads indeed

yep, all working fine until the upgrade to -5

downgrade to -4 and it's fine again

ok, I'll investigate later tonight - looks like I'll need to play around with your code a bit and add some debug - thanks for this

i'll have a go at debugging it if this isn't triggering any "ah that's because of X" thoughts

looking at the current yada code, it should work, but I don't disbelieve you!

the relevant yada code is here; https://github.com/juxt/yada/blob/master/src/yada/methods.clj#L128

if you have a fork of the yada code, or put in your project's checkouts/ you could put some debug in that yada chain and see what's going on

(but I'll investigate this myself if you don't want to do that)

sure, i'm happy to put some debug in yada

and i'll add your code to a test to make sure yada doesn't regress

@malcolmsparks: i'm currently mystified... my responses are threading their way through the GetMethod request chain... both of the prints happen just fine here https://www.refheap.com/108754 whether my GET response Deferred is returned already realized or not. if it's not already realized though, it hangs at some point later

given that it needs to be realized to pass through the chain i can't think of a mechanism for the problem

ok, there's something about the Deferred being returned... if i just return a (manifold.deferred/success-deferred (generate-string {})) then there is no hang, and similarly no hang with (m/return (generate-string {}))

but i don't get how, even with the problematic Deferred, it gets realized fine because it's value is threaded through the yada GetMethod request chain, but then hangs at some point later

@malcolmsparks: regarding the representations and If-Match. I guess you could make the etag generation only depend on the version and media-type of the representation (not the actual representation). e.g. (let [etag (sha (p/version (:resource ctx) ctx) media-type)])

@malcolmsparks: i don't think you will easily be able to reproduce the problem i am seeing with unrealized Deferred responses. something complex seems to be happening, and my only hypothesis so far is that it's a manifold Deferred chaining bug

@malcolmsparks: well i got a reproducible test-case https://www.refheap.com/108759

which fails with a single chained deferred, monads all stripped out

it looks like there is a bug in manifold too though, because

while @(er-api.service.handler/chain-delay-deferred 100 1000) does what you'd expect (wait for a second, then return 5050)

@(er-api.service.handler/chain-delay-deferred 100000 1000) hangs

@ordnungswidrig: in the yada code, when you see 'representation' it actually means 'representation-metadata' - this is lazy of me and I should update the code

representation-metadata is a map, containing media-type, charset, encoding and language

so etags are a function of the version and the representation-metadata

so it's already as you propose

I see. So the problem emerges when you want to have a „dynamic“ set of representations?

representation-metadata may also contain other things (the spec. leaves it open what other 'axes' you might add)

@ordnungswidrig: yes exactly

the spec. doesn't really anticipate that

you need to know up-front the entire set of representations you can support

I see, yada would need to „summon“ the actual resource to know that

the new RFCs are much clearer in these regards

@malcolmsparks: i created a manifold bug : https://github.com/ztellman/manifold/issues/48 . i don't think this is the root of the yada problem i'm having though - i can't see why chains would be 1000s long, and this bug doesn't occur until then

@mccraigmccraig: great - the fact your code works with -4 and not with -5 is evidence it's a yada issue, I'll investigate tonight