Responses inline :)

> On 18 Mar 2015, at 09:49, James Henderson <ja...@jarohen.me.uk> wrote:
> > On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
> > 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 there’s a general danger of this when writing tools that solve generic 
problems. The problem of discoverability is something that I found a lot of 
when I was writing a lot of perl as well. If you weren’t attending events and 
keeping up to date with what’s going on, you didn’t get to hear about all the 
cool things people were doing. I find the clojure IRC channel helps a bit with 
this.

> 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.

*nod* I haven’t dealt with this yet. This is something my forthcoming library 
‘kombucha’ (that i’m supposed to be hacking on right now, ho hum…) will have to 
deal with as well. I’m currently trying to figure out the best way to deal with 
what leiningen calls profiles while keeping the configuration format sane and 
simple. I see you’ve got some support for that, so I’ll be having a look 
shortly.

> 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.

Yes. Sorry, I didn’t mean it as a negative comment. I think batteries included 
is great for getting people going quickly and I appreciate you’ve gone to some 
efforts to make it removable. However, you focus on the reloaded workflow 
aspect considerably in the documentation so I was under the assumption that was 
the case you were aiming to support.

> 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.
> 
> 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.

I expect this could get lengthy so I’ll follow up offlist. More than happy to 
work together if our ideas coincide.

James

-- 
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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to