Thanks - thoughts inline :)

On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
>
> Hi James, 
>
> ‘component’ is a difficult term to google for, so I hadn’t come across 
> your project :) 
>

Same problem here when I started writing Phoenix - there could be many 
libraries trying to solve the same problem!
 

>
> I think your module had slightly different design goals from mine. Mine 
> were: 
> * everything in one config file (although i also provide support for 
> separate data-config and system config) 
> * be minimal. i’ve got a bunch of things i’m building on top of oolong at 
> present that will together provide a more “complete” experience 
>

Fair enough! I went for giving people the option of either one config file 
or multiple (after all, you don't *have* to use :phoenix/includes!) mainly 
because I got a lot of requests in Nomad (Phoenix's predecessor) for 
separate apps within the same company to share common configuration.
 

>
> I see you note that phoenix is ‘batteries included’. That’s a great 
> experience for new users, but i wasn’t trying to build that on this 
> occasion :) The leiningen template and plugin are also nice additions, and 
> reloaded workflow integration is very handy. 
>

Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from 
Docker) which is significantly different from 'batteries included'. I'm not 
a fan of 'batteries included' - it tends to mean libraries that are hard 
for users to customise at a later date, which (to me, and to you as well by 
the sounds of it) goes against Clojure ideals. Phoenix is deliberately 
written as a standalone runtime library, which composes with whatever other 
systems people dream up, and a separate, lightweight plugin (not so 
composable), which essentially just bootstraps the library and saves people 
the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so 
wish.
 

>
> Reloaded workflow has been an experience for me. I haven’t yet managed to 
> get it working in the face of compile errors. I find myself restarting the 
> leiningen repl about as much as before. For this reason I chose to keep it 
> separate and delay dealing with it for a few weeks. Have you managed to 
> overcome these problems? I’m definitely interested in knowing how if so. 
>

Happy to help with these - do you want to post some specifics? As a 
starting point, I've found that including an 'emergency nREPL' - an nREPL 
that starts before the application (and doesn't depend on the application 
compiling) gets you a long way. If the application doesn't compile, the 
system doesn't start, but I think that's actually preferable than half a 
system.
 

>
> I’ve only really given phoenix a few minutes of my attention so far, but I 
> like what I see and I’m liable to steal ideas for some of the things i’ll 
> be building on top of oolong. Feel free to reply offlist if you have any 
> further questions. 
>

Feel free to steal ideas from Phoenix - that's what open source is all 
about! More than happy to work together on this as well though - seems like 
we have both come to very similar conclusions about how we want to wire up 
Clojure components.
 

>
> James 
>
> > On 18 Mar 2015, at 09:07, James Henderson <ja...@jarohen.me.uk 
> <javascript:>> wrote: 
> > 
> > Hi James, 
> > 
> > This looks very similar to Phoenix - a project I've been working on for 
> the last few months. It's pretty likely you hadn't heard of it (and that's 
> fine - it's not been hugely publicised!), but if you have, I was wondering 
> whether there was anything about it that you felt was missing/a bad design 
> decision? If so, would be great to get your feedback! 
> > 
> > Cheers, 
> > 
> > James 
> > 
> > On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: 
> > I've been using stuartsierra's handy component library for a while now, 
> but I wanted an easier way of connecting components together. 
> > 
> > To that end, I wrote oolong. The main mode of operation is to take an 
> edn configuration file and connect the specified systems and components. 
> > 
> > https://github.com/jjl/oolong 
> > 
> > https://clojars.org/oolong 
> > 
> > Feedback welcome. I spent quite a while documenting it so hopefully it 
> should be fairly clear to understand. 
> > 
> > James 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> <javascript:> 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com <javascript:> 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to a topic in the 
> Google Groups "Clojure" group. 
> > To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/T_skapDqZ0U/unsubscribe. 
> > To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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/d/optout.

Reply via email to