i personally think this was an important change as the default encoding
of maps to be sent as json is somewhat lossy (keywords converted to
strings, would never be able to get this 100% perfect using json alone
without a more complex encoding solution). encoding to edn is the
perfect solution to this.
since browserchannel pretty much requires the final sent data to be
json encoded, we just serialize the clojure data being sent to an
edn string within a root json object.
this does ultimately mean we have to do a little bit of pre-parsing
of sent and received maps to encode/decode properly and make it
completely transparent to application code, but i think it's an
acceptable tradeoff.
i apologize to anyone looking at this commit and wondering why i would
do this, but all these little "off" formatting things have been bugging
me all day while looking at this code. i simply had to do something.
up until now, a single event handler "on-session" could be provided to
wrap-browserchannel which would be invoked each time a new client
session was created. it was then the application's responsibility to
register listeners for close/receive events inside this on-session event
handler.
this was kind of clunky honestly. basically every application would want
to use all of these events, so why not reduce the boilerplate needed?
this change makes it so a map of event handlers (:on-open, :on-close and
:on-receive) can be passed under wrap-browserchannel's options map (in
the key :events). this makes it simpler for an application to set up
browserchannel event handlers, and it works in basically the exact same
way as the clientside event handler registration works right now
it was horribly out of date, didn't even build (broken dependencies),
and when i briefly looked into fixing it up, i quickly realized that
aleph/netty has changed quite a bit in the few years since this adapter
was last touched. i really don't know anything about aleph/netty as
i've never used it so i don't think it's a good idea for me to be trying
to update this.
ultimately i think removing this is the best option for now rather then
keeping it around in a severly out of date and broken state.
Gered
