Fork me on GitHub
#yada
<
2017-08-04
>
lxsameer08:08:33

there's no doc around it, also I saw some where in SSE doc which mentioned it does not

lxsameer08:08:39

how can I do that

malcolmsparks08:08:52

Aleph supports websockets. They are not HTTP but an 'upgrade' protocol. Hence yada doesn't say much. See Aleph's docs

lxsameer09:08:25

I see, thanks

dominicm10:08:10

https://datatracker.ietf.org/doc/draft-west-first-party-cookies/ better link on SameSite attribute. Looks like Mozilla were involved 🤔. Don't know enough about IETF process to make judgement on it's viability as a standard. The expiration of nearly a year puts me off though.

jumblemuddle19:08:22

When using yada.resources.classpath-resource/new-classpath-resource, it works fine with bidi.ring/make-handler routes, however once I switch to bidi.ring/make-handler routes handler (with a handler function which can return yada.yada/handler classpath-resource, it doesn't work. It it something to do with bidi's special protocols not working when using make-handler with a handler function?

jumblemuddle19:08:03

Here's what I got to work: http://sprunge.us/PRdE Why would I have to have the handler twice? Perhaps the first one only does the bidi protocol stuff?

jumblemuddle19:08:51

Admitedly my handler function could just act as an identity for cond :default.

dominicm19:08:53

@jumblemuddle What happens if you do :default route?

jumblemuddle19:08:21

@dominicm That seems to be working. 👍

dominicm19:08:38

@jumblemuddle (yada/handler) turns a yada resource into a ring handler.

jumblemuddle19:08:39

Just seems strange that the classpath resource needs to be in the routes and not just the handler.

dominicm19:08:38

It's because of the way you're handling it I think.

jumblemuddle19:08:44

Because bidi.ring/make-handler needs the bidi/Matched stuff, I guess.

jumblemuddle19:08:58

(From yada.bidi)

dominicm19:08:00

^^ you can do this

jumblemuddle19:08:40

I could create my own bidi/Matched implementation?

dominicm19:08:03

absolutely, or bring in yada.bidi? 😉

jumblemuddle19:08:15

yada.bidi has been brought in. My confusion was that yada.resources.classpath-resource wouldn't work when I gave it in the handler function.

jumblemuddle19:08:22

It has to be in the routes and the handler.

jumblemuddle19:08:09

Even with a [true :public] entry in routes and a :default (new-classpath-resource...) in the handler, it wouldn't work.

dominicm19:08:50

I'm a little confused by your case function

dominicm19:08:24

or cond, yeah. Why is it there?

jumblemuddle19:08:16

Basically for /api it sends a 200 and an api resposne, and for misc other matching routes, which are defined elsewhere, it'll do some SSR stuff.

jumblemuddle19:08:24

Then for resources, it should return those.

jumblemuddle19:08:56

The whole issue is that those other misc routes need to be defined elsewhere and included here.

dominicm19:08:06

It's more that, I've never seen a cond in use. Oh, it's because you're using :keywords

jumblemuddle19:08:19

Oh, basically it's just pairs of if-else's. Each lines starts with a conditional check, then the second expression is what should be done if that conditional is true.

dominicm19:08:31

I should be clearer. I've never actually needed to use a cond for this sort of purpose. Normally I have bidi resolve to a handler directly.

jumblemuddle19:08:55

Oh, sorry... my bad. 😛 I almost always do as well; the reason I'm trying to here is because of those co-located other routes, which will always be keywords, so I need a handler function to translate those keywords into handlers.