Looks like a great library... It would be intriguing to try to use something like DatomicScript for the app state of an Om application.
(Edit: Read in a separate blog post that the author of DatomicScript is thinking about this already)
At the end of the day though, I still think someone (smarter than me) needs to figure out the full end-to-end solution for datomic+clojurescript, with both client and server elements.
The core question: Does it make sense to map datomic to a REST API on the server, then consume the REST on the client? Or, does it make more sense to build something more clojure-like for the client-server interface, and remove REST from the equation entirely?
Datomic is bundled with a REST server: http://docs.datomic.com/rest.html. And it includes an endpoint to subscribe to a stream of Server-Sent Events, which lets you drink from the transaction-report firehose. But there is a lot of data in that stream. I'm writing a production Pedestal app, and I could definitely use the capability to store my data on the client in the same shape as Datomic and query it with Datalog.
A seamless datomic <-> clojurescript client/service framework is needed. I am just getting started with Om and hope to experiment with some ideas in that space. I don't think REST is the right approach. I would like to abstract everything to an AVET or sequence thereof.
i think you want the application-facing interface to remain REST (links between entities, HATEOAS), but the REST/CRUD client's transport layer wouldn't be traditional http/ajax, rather implement similar capabilities to a Datomic Peer. So a CRUD READ would query a cached Datomic index rather than touch network. Create, Update, Delete could be http/ajax or could be something else like a websocket; I believe transport to be orthogonal to the fundamental principles of REST application design.
Exciting prospect. How about DataScript for your app state + tx-listen/om-sync mirroring transactions? Might require wrapping the datascript/transact! call, and I haven't thought about reading from the cliente. Maybe as simple as lazily mirroring datascript/q calls and filling those back into the DataScript map.
Why even limit it to Clojure and ClojureScript? I could use this from JavaScript or PureScript as an immutable local store to replicate/merge with the backend asynchronously.
How about another rename? DatomicScript was clearly a bad idea and possibly infringing. "DataScript" is just misleading. Using "_____Script" creates the appearance that is a scripting language. Perhaps "_____DB" or "_____JS" would be better.
[+] [-] drcode|12 years ago|reply
(Edit: Read in a separate blog post that the author of DatomicScript is thinking about this already)
At the end of the day though, I still think someone (smarter than me) needs to figure out the full end-to-end solution for datomic+clojurescript, with both client and server elements.
The core question: Does it make sense to map datomic to a REST API on the server, then consume the REST on the client? Or, does it make more sense to build something more clojure-like for the client-server interface, and remove REST from the equation entirely?
[+] [-] davidrupp|12 years ago|reply
[+] [-] tony_landis|12 years ago|reply
[+] [-] dustingetz|12 years ago|reply
[+] [-] vdm|12 years ago|reply
[+] [-] mvzink|12 years ago|reply
[+] [-] puredanger|12 years ago|reply
[+] [-] dj-wonk|12 years ago|reply
[+] [-] dang|12 years ago|reply
[+] [-] imslavko|12 years ago|reply
If so, it could lead to some features like latency compensation and stubs similar to Meteor's MongoDB and MiniMongo. That would be cool.
[+] [-] tonsky|12 years ago|reply
[+] [-] sethev|12 years ago|reply
[+] [-] puredanger|12 years ago|reply
[+] [-] ibdknox|12 years ago|reply
[+] [-] skybrian|12 years ago|reply
Datalog is apparently a subset of Prolog that's used by Datomic (a commercial database) as its query language.
[+] [-] danneu|12 years ago|reply
[+] [-] sdegutis|12 years ago|reply
[+] [-] jchrisa|12 years ago|reply
[+] [-] tonsky|12 years ago|reply
[+] [-] gcv|12 years ago|reply
[+] [-] coolsunglasses|12 years ago|reply
[+] [-] Skinney|12 years ago|reply
[+] [-] shaunxcode|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dj-wonk|12 years ago|reply
[+] [-] dj-wonk|12 years ago|reply