Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 2019 00:41
    gammazero commented #346
  • Jan 27 2019 00:59
    fuath starred wamp-proto/wamp-proto
  • Jan 26 2019 13:51
    deepaksood619 starred wamp-proto/wamp-proto
  • Jan 25 2019 12:53
    oberstet labeled #346
  • Jan 25 2019 12:53
    oberstet labeled #346
  • Jan 25 2019 12:53
    oberstet labeled #346
  • Jan 25 2019 12:53
    oberstet opened #346
  • Jan 21 2019 08:03
    Niputi starred wamp-proto/wamp-proto
  • Jan 17 2019 21:54
    karenpeng commented #345
  • Jan 17 2019 07:22
    oberstet commented #345
  • Jan 17 2019 07:21
    oberstet commented #345
  • Jan 17 2019 07:07
    oberstet commented #345
  • Jan 17 2019 01:44
    karenpeng starred wamp-proto/wamp-proto
  • Jan 16 2019 21:11
    karenpeng commented #345
  • Jan 16 2019 20:11
    karenpeng commented #345
  • Jan 16 2019 16:44
    meejah commented #345
  • Jan 16 2019 13:05
    KSDaemon commented #344
  • Jan 16 2019 12:20
    goeddea commented #344
  • Jan 16 2019 09:36
    KSDaemon commented #345
  • Jan 16 2019 09:26
    oberstet labeled #345
Entropealabs
@entropealabs_gitlab
neither, if you have a key in your kwargs called raw_image the value would use the method you posted
and then you would send the serialized structure over the wire, your peer that receives the message wouldhave to know how to unencode that specific key
so that is best left up to the implementer, and not the library, although I guess you could create a binary type, that your client would know how to handle, but it's specifically mentioned that clients/router shouldn't have to look at the arguments passed
msgpack doesn't have that issue, as it can handle binary data natively
so you can just send the plain old binary data
Justin Turner Arthur
@JustinTArthur
@entropealabs_gitlab, are you sure? This is why I’m bringing it up, as the spec isn’t clear. It’s referenced in section 5.2.1 pertaining to serialization itself, which makes me think it’s a requirement for JSON serialization, i.e. up to library maintainers like us to include it
1 reply
Entropealabs
@entropealabs_gitlab
I'm pretty positive, json is not a binary protocol, it's just mentioning how you would encode binary data in your JSON if you need to
Justin Turner Arthur
@JustinTArthur
I figured it was specifically for that reason that it’s a requirement in a WAMP implementation, to workaround lack of low-level support.
Entropealabs
@entropealabs_gitlab
how would you know that the value is binary data, and not just some other random data?
you could encode that in an object, within your arguments, but again, that would be up to the user, not the library
Justin Turner Arthur
@JustinTArthur
Because it’s prefixed with a null character. And if that is indeed how, then presumably we are not allowed to use null-prefixed strings for any character string purposes
1 reply
Entropealabs
@entropealabs_gitlab
I don't think you want to scan every key and value in your arguments
Justin Turner Arthur
@JustinTArthur
It would be neat if it was up to the application layer, but if so, why mention a format for it in the spec? Someone with their kwargs[“raw_image”] can pack bytes however they want to.
@entropealabs_gitlab I definitely don’t, which is why I’m asking :)
Entropealabs
@entropealabs_gitlab
right, I think it's just a suggestion on best practices for doing to
"Binary data follows a convention for conversion to JSON strings"... follows a convention
Justin Turner Arthur
@JustinTArthur
@oberstet or @goeddea can you weigh in? Is it a best practice suggestion for application developers or a specification for WAMP implementors?
Entropealabs
@entropealabs_gitlab
Good call, I'm definitely not positive, but based on other statements in the spec about not looking at the arguments, I think it's at the application level
1 reply
Justin Turner Arthur
@JustinTArthur
@entropealabs_gitlab for reference, autobahn-python does just that as part of the serialization/deserialization process.
Entropealabs
@entropealabs_gitlab
it looks for binary data?
Justin Turner Arthur
@JustinTArthur
yep
Entropealabs
@entropealabs_gitlab
interesting
Justin Turner Arthur
@JustinTArthur
It does it for every message part, including details, options, and string-packed URIs.
Entropealabs
@entropealabs_gitlab
it looks for binary data in the URIs?
Justin Turner Arthur
@JustinTArthur
Yes, as they are transported as character strings. Serializer code/Deserializer code
Entropealabs
@entropealabs_gitlab
well now I'm intrigued
Justin Turner Arthur
@JustinTArthur
It’s easy in the stdlib Python JSON mechanics to make it part of the parsing/unparsing process so you don’t iterate over your keys/values again following standard JSON parsing. As you can see in their implementation though, they won’t bother with the second-visit approach if you chose a C-based JSON parser; I may end up doing the same.
Entropealabs
@entropealabs_gitlab
seems like a nightmare, that would be a fun bug to find a few years down the road
somehow you have a different json parser
Justin Turner Arthur
@JustinTArthur
Jason for Elixer doesn’t look tooo difficult to extend in your case at least
Entropealabs
@entropealabs_gitlab
yeah, I don't think it would be a huge deal
Entropealabs
@entropealabs_gitlab
@JustinTArthur did you ever get anymore clarification on this?
Justin Turner Arthur
@JustinTArthur
I didn’t. I went ahead and implemented it where easy.
My router-less WAMP server kit, serverwamp, is now available. Would love to hear thoughts on the design.
1 reply
Tobias Oberstein
@oberstet
^ bit late .. but here are some notes:
  • the transparent binary support within JSON was designed for args/kwargs as a new scalar type (that is, it can be used for eg a list of binaries or a dict with binary values or more complex types)
  • we invented that feature ad-hoc, as we needed it, but the spec definitely lacks here
  • if a WAMP implementation wants to support it, the best place is deep inside a serializer library
  • for python, this is done easily and cleanly, it can be added in a couple of lines of code in other sane languages as well
  • the resulting wire traffic is not strictly JSON RFC compliant, as the octet chunks that result from conversion are not necessarily valid UTF8 after the \0 .. but that means "string end". left kinda undefined in JSON, so we occupy that empty space=)
Justin Turner Arthur
@JustinTArthur
Thanks for the replies, @oberstet
Justin Turner Arthur
@JustinTArthur
What’s the best practice for handling an internal component or router error, e.g. the wamp component has an unhandled exception while handling an INVOCATION or the wamp router has an unhandled exception while handling a SUBSCRIBE?
6 replies
Cameron Elliott
@cameronelliott
Hi everyone, I am a salty middle-aged developer, and have just discovered WAMP. I was working on a Websocket router, and in a rare moment of lucidity, I asked myself, "maybe this has been done before?". Thus I started searching and discovered WAMP, and the router implementation I am using.
I think WAMP is freakin' fantastic!
I am noticing some interesting edge cases that might be of interest to the spec authors.
In particular, I discovered that Wampy.js won't pass pub/sub messages to the router when the topic name is "foo-bar"
But wampy.js will pass pub/sub messages to the router when the topic is "foo.bar"
I also discovered adopted router works fine with the hyphenated version, "foo-bar", differing from Wampy.js
So, I have been diligently reading 5.1.1.1 and 5.1.1.2, regarding Relaxed vs Strict URIs
Cameron Elliott
@cameronelliott
I personally find the spec a bit confusing regarding URI rules, and I have written my thoughts up a little more in depth here. If there is a spec-author or maintainer that wants to discuss further or in-depth, please let me know. https://github.com/KSDaemon/wampy.js/issues/135#issuecomment-715630405
Cameron Elliott
@cameronelliott
In particular the spec says "While the above rules MUST be followed, following a stricter URI rule is recommended: URI components SHOULD only contain lower-case letters, digits and _.".
Where "the above" refers to the Relaxed URI rules. I think the spec should explain if the regexs are normative or non-normative, and I suggest that the spec explain from three perspectives who 'must', and who 'should' follow the relaxed vs. strict rules.
I am guessing intent was that: applications can follow either strict or relaxed, but client libraries and routers 'must' allow both strict and relaxed URIs. (Which is not the case with Wampy.js at the moment.)
:smile:
Andrew Gillis
@gammazero
Here is my take on it, reposed from above issue:
  • Yes, applications should use the strict spec. This guarantees them a compatible URI.
  • Client libraries may allow both, but a client library could choose to be opinionated about this and decide to restrict to only using strict. This is likely as the library implementer does not want to handle issues arising from someone's use of a client not working with a router that is configured to only handle strict spec.
  • Routers should allow both, but that is a choice and is configurable.