Abstract & Scope Discussion

MandarinConLaBarba commented 10 years ago

Slogan

Code = information Art = information Code = Art

OK so here's what I envision regarding the basic function of clojart.

MVP Functionality

Clojart allows a user to provide a string of code, or a URI to a source file (and later perhaps to a git repo). The user then can provide additional configuration (e.g. a visualization module like 'Matisse' or Cubism). Then the user hits the 'create' button and an immutable object is created that stores the code string, the configuration (which includes the version of the visualization module and anything else necessary). This object can be used to produce the same rendering (an image) every single time w/o variation.

For MVP, we probably only need one visualization module, but it should be somewhat compelling visually.

MandarinConLaBarba commented 10 years ago

cc @j0ni

j0ni commented 10 years ago

It sounds like processing will happen on the server. Any thoughts what the nature of the processing artifact will be? SVG? Some home-made format (probably EDN for efficiency if we're going for 100% clojure(script) and data == code as dogfood, so to speak)?

Seems to me like there is a lot of infrastructure we want to decide up front, which is independent of the actual application. Here's what I think we should consdier:

Backend

HTTPkit - (async HTTP server)
Compojure - routing macros
core.async layer to allow us to use core.async from Compojure handlers without crashing and burning. See this thread.

Frontend

Om
Either using the Om native transact! state management, or perhaps this architecture (which is what Circle uses).

App Logic

This is the fun clever stuff. Not sure what goes here at all. Of interest, there's a clojure port of Processing that might be interesting:

Quil

That's it for now, please feel free to head me off if I'm going down the wrong path here.

MandarinConLaBarba commented 10 years ago

This is excellent - I created a wiki page for the stack...do we want to keep it there or just discuss in this issue for now?

I will review Quil and the other links above. This all looks good though.

So for App Logic, I'm thinking it will be broken out into separate reusable/pluggable components:

The form (accept the code, or the URI, and other metadata)
The parser (converts the code into clojure lists). For clojure it's basically an identity function I guess?
The reader - transforms the clojure list representation of the code (basically kind of like an AST I guess) and converts it into some list of values. Basically this is an algorithm that extracts some metrics from the code, raw data w/ which we'll need to feed into the visualizer.
The visualizer - basically this is an interface (or protocol), for which we'll need at least one implementation. I'd imagine this will be done on the client? Or maybe not..thoughts?

All the other stuff is small potatoes I guess, just figuring out how to present stuff, an index page, browsing or whatever...something simple.

j0ni commented 10 years ago

do we want to keep it there or just discuss in this issue for now?

We can discuss here, keep the "current thinking" snapshot there.

That processing model looks good. I think Clojure code == EDN, so we might be able to just parse it using the clojure.edn API. If not, maybe we could use the Clojure compiler.

That's also a possibility for constructing some AST type structure. We need to see if the Clojure compiler is sufficiently modular that we can use different phases without having to deal with the rest.

The visualizer - basically this is an interface (or protocol), for which we'll need at least one implementation. I'd imagine this will be done on the client? Or maybe not..thoughts?

I really don't know. I guess it depends what kind of interactivity we want. My first thought was SVG, because that gets you scaling and zoominess and the like, without having to write your own renderer. But if we want to do fun transformations or animations (which is way out of my experience) maybe we'll need to find a d3 wrapper (or write one!) and write a component around that.

MandarinConLaBarba commented 10 years ago

Cool, I probably need a few days just to check all this stuff out. I've just done the clojure heroku tutorial which was easy..

MandarinConLaBarba commented 10 years ago

Few more items:

What about database...the Om tutorials (and a lot of other clj projects) suggest datomic
Do you know if there are any lein templates out there that match most of what we're looking for?

j0ni commented 10 years ago

Datomic would be fun. Circle rejected it for either business or technical reasons depending on who you speak to, but in either case I don't think the reasons would apply to us.

Either that or something like Neo4J would be interesting.

As for templates, maybe so... but I'd quite like to build this from the ground up for experience. I'd also add Stuart Sierra's Component framework to the mix on the server side.

MandarinConLaBarba commented 10 years ago

Cool, I'll check out Component.

Looking at the Datomic products suite, the free version is "limited to 2 simultaneous peers and transactor-local storage"...any idea what the significance of this is?

Or maybe there are some low/no cost hosting options..

j0ni commented 10 years ago

I have a pro trial license, and a dude I met at Lambda Jam mentioned that the expiration of trials was going to be junked some time soon (Cognitect employee). I have emailed them to ask about it.

The significance is I think that you're limited to in-memory dbs, or perhaps local storage, or something like that. Not what you want.

Neo4J would probably be just fine. The QL and perfect fit for Clojure is what appeals about Datomic.

MandarinConLaBarba commented 10 years ago

Propose we use something really simple/free until we know more about what database would suit our needs...maybe mongo?

j0ni commented 10 years ago

Works for me.

CongoMongo or Monger? Take a look and see what you think.

MandarinConLaBarba commented 10 years ago

OK so I'm not enough of an expert to really care. I think either one, and based on the stuff I see on the net it's mostly a partisan divide..so I say CongoMongo, unless you have favorable experience w/ the other.

j0ni commented 10 years ago

Works for me. I've played with monger in the past, circle uses congomongo. The latter is less gimmicky and has less of a pointless DSL feel which I like. OTOH monger is clojurewerkz which is an amazing bunch (or mostly amazing guy) so... Whatever :)

CM sounds good to me.

j0ni commented 10 years ago

Ooh, this looks interesting for taking care of a lot of plumbing:

https://github.com/danielsz/system/

Built on top of Stuart Sierra's Component, which I like a lot.

MandarinConLaBarba commented 10 years ago

I'll check it out after component.

MandarinConLaBarba commented 9 years ago

So it seems that system has a Monger component...does that change your view on whether to use CongoMongo?

j0ni commented 9 years ago

Meh, not really. It's not a huge piece of work either way - maybe even make a System component for CongoMongo and make a PR.

On Fri, Oct 17, 2014 at 1:02 PM, Mandarin Drummond <notifications@github.com

wrote:

So it seems that system has a Monger component...does that change your view on whether to use CongoMongo?

— Reply to this email directly or view it on GitHub https://github.com/orchard-labs/clojart.io/issues/1#issuecomment-59567358 .

MandarinConLaBarba commented 9 years ago

Started work on this here

orchard-labs / clojart.io