I believe the semantics can be simplified as this:
* the server (clj) can disconnect at any time
* the client (cljs) has the responsibility of
(1) informing the user
(2) reconnecting
(3) figuring out what went wrong
in such events
I believe this is both necessary and sufficient.
It's sufficient in that a dropped network connection can be viewed as
"server decided to disconnect."
It's also necessary in that -- if we want defensive programming and to
avoid DOS attacks by malicious clients, it's important for the server to,
at some point, say "F U client, you're out of tokens; I'm disconnecting
you" or to say "F U client, I can't send data to you; I'm disconnecting
you."
This is not CSP semantics, but I believe it's both necessary and sufficient
for having "core.async" across the network -- the semantics being
* the server can, at any time, arbitrary disconnect a client
* it's the client's job to inform the user / try to reconnect
On Sat, Jan 25, 2014 at 3:17 PM, Michał Marczyk <michal.marc...@gmail.com>wrote:
> If the application is structured in such a way that messages from the
> other side of the client/server divide are put on channels upon
> arrival, which seems to be a reasonable idea, why not encapsulate the
> connection-handling logic in a black box exposing a (bunch of)
> channel(s)?
>
> On 26 January 2014 00:01, Patrick Logan <patrickdlo...@gmail.com> wrote:
> > This seems like more trouble than it is worth. There are almost
> certainly suitable but more established protocols and implementations for
> the problem at hand. Anyway, maybe it's worth exploring. To me it seems to
> muddy the waters for what core.async seems intended to provide, which seems
> to me to be fairly straight-forward CSP.
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
