> It's not clear to me that the server side should be tied to Om
> specifically. It seems like the requirement is more to have a server
> component that can pass messages / state changes in a generic way to
> clients (probably using core.async channels, with the ability to use
> websockets etc. as the underlying transport). This server component
> would be useful for all kinds of clients (not just Om, not just
> Clojurescript, maybe even other server systems).
>
> I've hacked some stuff together that does this kind of thing for
> specific projects, but it would be nice to get a solid standard
> library in the ecosystem for this.

We have a concrete need for a system like this and in fact already have
a prototype in production (which uses browserchannel as opposed to
websockets, but these should be interchangeable) with ampq messaging and
http wrapped in core.async and Om on the front-end, but we are working
through some issues relating to scaling while providing eventual
consistency across a number of web front-ends.  The end goal is
essentially materialized views in the client.

We would also be very interested in working with other folks to provide
something with general applicability to the whole community.  Please let
us know if you'd want to contribute!

DD

(2014/02/16 10:43), Mikera wrote:
> 
> 
> On Sunday, 16 February 2014 09:26:18 UTC+8, Conrad wrote:
> 
>     On Thursday, February 13, 2014 8:55:00 PM UTC-6, David Nolen wrote:
>     > I've been banging the drum about Om & modularity for a while now
>     and I've come up with the very beginning of a simple reusable
>     component that I think demonstrates the power of Om's emphasis on
>     modularity and application wide state management:
>     >
>     >
>     >
>     > http://github.com/swannodette/om-sync
>     <http://github.com/swannodette/om-sync>
>     >
>     >
>     >
>     > The whole point of Om is to create a universe of shareable
>     components. I hope this gets people thinking about the possibilities.
>     >
>     >
>     >
>     > Feedback welcome!
>     >
>     >
>     > David
> 
>     I agree that creating an ecosystem of components is where the future
>     is... I'm surprised that there isn't a "ReactjsUI" library yet.
> 
>     Stop me if this is obvious, but it seems like the natural conclusion
>     of Om is to have an Om-server library as well to build html
>     server-side, and then have an Om-bridge component or something that
>     automagically bridges between client and server. Then, when a
>     client-side component updates any state that originates in the
>     server part, the existing Om interfaces probably are already
>     comprehensive enough that the Om-bridge component could just
>     transparently use AJAX to push those updates into the state of the
>     Om components residing on the server.
> 
> 
> It's not clear to me that the server side should be tied to Om
> specifically. It seems like the requirement is more to have a server
> component that can pass messages / state changes in a generic way to
> clients (probably using core.async channels, with the ability to use
> websockets etc. as the underlying transport). This server component
> would be useful for all kinds of clients (not just Om, not just
> Clojurescript, maybe even other server systems).
> 
> I've hacked some stuff together that does this kind of thing for
> specific projects, but it would be nice to get a solid standard library
> in the ecosystem for this.
> 
>  
> 
> -- 
> 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.

Reply via email to