Fork me on GitHub
#yada
<
2015-08-26
>
malcolmsparks08:08:15

"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."

malcolmsparks08:08:00

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.

malcolmsparks08:08:24

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

malcolmsparks08:08:11

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.

mccraigmccraig11:08:45

@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

mccraigmccraig11:08:09

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

malcolmsparks11:08:18

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?

malcolmsparks11:08:46

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

mccraigmccraig11:08:33

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

malcolmsparks11:08:34

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

malcolmsparks11:08:53

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

malcolmsparks11:08:48

what do you mean by vanilla in this case?

malcolmsparks11:08:58

does m/return return a deferred?

mccraigmccraig11:08:07

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

malcolmsparks11:08:43

it's the cats monads indeed

mccraigmccraig11:08:03

yep, all working fine until the upgrade to -5

mccraigmccraig11:08:11

downgrade to -4 and it's fine again

malcolmsparks11:08:40

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

mccraigmccraig11:08:51

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

malcolmsparks11:08:03

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

malcolmsparks11:08:21

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

malcolmsparks11:08:37

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

mccraigmccraig11:08:04

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

malcolmsparks11:08:11

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

mccraigmccraig12:08:26

@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

mccraigmccraig12:08:19

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

mccraigmccraig12:08:54

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 {}))

mccraigmccraig12:08:38

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

ordnungswidrig13:08:40

@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)])

mccraigmccraig13:08:10

@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

mccraigmccraig14:08:34

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

mccraigmccraig14:08:47

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

mccraigmccraig14:08:24

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

mccraigmccraig14:08:44

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

malcolmsparks14:08:14

@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

malcolmsparks14:08:29

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

malcolmsparks14:08:46

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

malcolmsparks14:08:56

so it's already as you propose

ordnungswidrig14:08:19

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

malcolmsparks14:08:23

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

malcolmsparks14:08:46

the spec. doesn't really anticipate that

malcolmsparks14:08:12

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

ordnungswidrig14:08:25

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

malcolmsparks14:08:26

the new RFCs are much clearer in these regards

mccraigmccraig14:08:09

@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

malcolmsparks14:08:52

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