Ok, so I've thought a little more about the architecture of a Clojure-based, composable blogging system. I put up my initial notes in this github repo: Stefon <https://github.com/twashing/stefon>. I've ordered the system components, based on core functionality, outwards.
- There would just be a core data model of posts, assets and tags, that would exists as definitions, and could be pulled into a runtime soup. - Then one has your CRUD + List + Find functions for those pieces of data. - Weaved into those core functions, would be a workflow that would handle preview, collaboration / editor review, versioning, and, I think an interface to the outside (plug-in) world. I've deliberately proposed a small core, so that you can use only the pieces you absolutely need. Additionally, I think it encourages a clean design, forcing explicit interaction semantics between system components. If we accept this premise, the only question then, is what mechanism we should use to separate the core of stefon, from the rest of its plug-in components. Now, I was looking into the nrepl protocol<https://github.com/clojure/tools.nrepl>. I think it conceptually gives us the separation we need, with the added bonus that a stefon service, and it's plug-ins, could be in separate locations. But while I like the concept, I think the host would need a way to i) declare the stefon service (nrepl versioning?), ii) list / publish actions (??) iii) pass around binary data (base64 encoding?). Also, I saw that there was a discussion around updating the nrepl protocol (nRepl.Next<https://github.com/clojure/tools.nrepl/wiki/nREPL.Next>), and don't know if that's been implemented. I think the first step is to get a clean plugin architecture (ie, communication channel) around the above core functions. The idea is that the core stefon service publishes it's actions, and it's up to each plug-in to decide what, if anything, they want to do with it. So for example, if I fire up a stefon service in my repl, I can programmatically pull some txt or rtf from my filesystem, and add a blog entry. Stefon will notify this action, but if no plug-ins have registered, then nothing happens. The entry just sits in memory until the VM shuts down. Now, if a Mongo plugin has registered to listen for new blog posts, it will get that message, and persist the data out to some configured location. And of course stefon would be able to listen for a plug-in to supply data. So a web UI plug-in could pass stefon a new blog post. Internally, the same wiring occurs. And the Mongo plug-in would see the new post, and persist it. Given this last scenario, I think this architecture would allow composability, with the trade-off of being very communication heavy. Having said that, I like this approach, and have some ideas as to the tools needed to get the job done. Also, I'll want to know if nrepl is a good fit. And if not, what other approach to take. Thoughts? See Stefon here <https://github.com/twashing/stefon>. Thanks Tim Washington Interruptsoftware.ca <http://interruptsoftware.ca/> / Bkeeping.com<http://bkeeping.com/> On Thu, Jul 18, 2013 at 12:25 PM, Timothy Washington <twash...@gmail.com>wrote: > Hadn't thought about spam detection, comment design, or versioning. But I > like the ideas a lot. I'll design with these features in mind. > > > > > On Thu, Jul 18, 2013 at 12:17 PM, Thorsten Wilms <t...@freenet.de> wrote: > >> On 07/18/2013 04:24 PM, Timothy Washington wrote: >> >>> I know that I currently wish I had a Clojure weblog engine that I could >>> stick into a site I'm building. If there's already something available, >>> I'll obviously just use that. But otherwise, is this something that >>> would be interesting to people? >>> >> >> Oh yes. >> >> I put some effort into a blogging engine myself, but got sidetracked a >> lot. Repo: https://github.com/thorwil/**tlog<https://github.com/thorwil/tlog> >> >> It's written as single account blog, but since I'm using Friend, that >> should be straightforward to change. >> >> For editing, I rely on Aloha (http://aloha-editor.org/). The unfinished >> comment system works only with JS enabled and has no spam protection or >> email notifications. Comments can be nested and the design is meant to >> encourage people to read previous comments, before they add their own (this >> at the cost of varying distance between a comment and its Reply field). >> >> Having Aloha-like editing, but without inheriting such a chunk of JS, >> rather using ClojureScript would rock. >> >> One of the more interesting parts might be how pages are assembled: >> https://github.com/thorwil/**tlog/blob/master/src/tlog/** >> render/html/assemble.clj#L83<https://github.com/thorwil/tlog/blob/master/src/tlog/render/html/assemble.clj#L83> >> >> Further down the road, I wanted to look into versioning, perhaps backed >> by git and realtime collaborative editing. I haven't be traveling, lately :} >> >> >> -- >> Thorsten Wilms >> >> thorwil's design for free software: >> http://thorwil.wordpress.com/ >> >> -- -- 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.
