Sente v1.21 roadmap (future release)

[ptaoussanis]

• Switch ws-kalive-ms from fixed interval to sliding  #455
• Document [:chsk/close]
• Allow async Packers
• Add Edn + GZIP Packer
• Switch from Timbre to tools.logging?
• Drop *write-legacy-pack-format?*
• Improve docs re: heartbeat usage (Ref. comment)
• Anything else?

[awb99]

please update the demo/docs so that heartbeat useage is clearer.
I would say that the connection handling part of sente is the least documented,
with releases in the last 2 years a lot of things has improved (stale connections seem to
no longer occur), so it is important that everything related to state change is better documented.

• :ws-kalive-ms client side, server side or both? it says they should not be equal, why?
• :ws-ping-timeout-ms what happens thereafter? client side, server side or both?
• is this necessary:

(defmethod -event-msg-handler :chsk/ws-ping
  [{:as _msg :keys [event _id _?data _ring-req ?reply-fn _send-fn]}]
  (infof ":chsk/ws-ping: %s" event)
  (when ?reply-fn
    (?reply-fn {:unmatched-event-as-echoed-from-server event})))

(defmethod -event-msg-handler :chsk/ws-pong
  [{:as _msg :keys [event _id _?data _ring-req ?reply-fn _send-fn]}]
  (infof ":chsk/ws-pong: %s" event)
  (when ?reply-fn
    (?reply-fn {:unmatched-event-as-echoed-from-server event})))

• note that the demo uses a old version of sente, so most likely needs to be changed.

[awb99]

Why not move to telemere both clj and cljs? This would be a nice usecase at least.

[ptaoussanis]

@awb99 Thanks for the suggestions. Sente's documentation and examples could definitely do with a lot of updating and improvement - have just been triaging efforts and these didn't seem like a priority.

Happy to reconsider though if there's interest.

is this necessary:

Just to answer this one so long - this has never been necessary, it's just there to illustrate that you can use these events if you like. That should be made clear, I hadn't considered that someone might interpret it as a requirement.

BTW PRs welcome if you or anyone else had small improvements like this to suggest!

[ptaoussanis]

@awb99 Why not move to telemere both clj and cljs? This would be a nice usecase at least.

Sorry, I somehow missed this before.

That would definitely be a possibility, but I think I'd rather focus on minimizing forced dependencies. Users would then have the option of choosing to use Telemere (via its tools.logging support), or another library/framework of their choice.

Using Telemere via a facade like tools.logging does limit functionality (e.g. re: filtering and structured data), but I believe that the more advanced functionality is anyway usually more relevant for user-level code (not library-level code).

So it's a matter of tradeoffs.