Discussion  - 
 
Last week I ported +Johan Tibell's excellent ekg to work with +Kazu Yamamoto's webserver package rather than Snap. Johan has merged the patches which split out the Snap support to ekg/master. The link below goes to WebServer.hs from my ekg/webserver branch. It should be pretty clear how to get ekg working with a different web framework, eg. if +Michael Snoyman wants to add process monitoring to Yesod.

One thing I'm not sure about is how to abstract this properly. My branch just uses a cabal flag and CPP to select the dependencies and which module to use. Should we instead make separate packages (ekg-core and then ekg-snap, ekg-webserver, ekg-yesod etc.)?
Remote monitoring of running processes over HTTP. Contribute to ekg development by creating an account on GitHub.
4
Aleksey Khudyakov's profile photoJohn Millikin's profile photoNathan Howell's profile photoJohan Tibell's profile photo
19 comments
 
I think we should make separate packages. ekg-base, ekg, and then new ekg-snap etc packages.
 
What would be the difference between ekg-base and ekg?

Better to have just one base EKG package IMO.
 
+John Millikin ekg would be what it is today; a library for people who want to instrument any Haskell app without caring much about which webserver runs underneath. ekg-base would be used to build ekg, but also other frontends for e.g. Snap and Yesod.
 
So you'd have "ekg-base" with the metric collection logic, and "ekg-snap" with the Snap integration, and "ekg" which just re-exports functions from ekg-base and ekg-snap to provide the current API?

That seems a bit silly, since it wastes the nice "ekg" package name on what is essentially just a compatibility shim.
 
Having multiple packages seems like a waste, I wish Cabal would do a better job here. Could a 'ekg -fsnap -fwarp -fwhatever' dependency do the right thing?
 
+Conrad Parker I would love to write it but my current employment situation means I can't release it without permission and getting permission will take many months.
 
I think having 'ekg' be a fully functioning package is ok, even if it's just a re-export. Maybe using Debian-style names would be nicer, with libekg-base, libekg-snap, and ekg?
 
+Nathan Howell It would be bad idea. First it's not possible to specify which set of flags do you need if you depend on ekg. And if two packages require different set of flags you are lost.
 
+Johan Tibell Controlling backend by flags is clearly the wrong thing to do here IMO. Separating the web logic into ekg-{snap,yesod,wai,...} would be a lot better. I don't think the existing ekg needs to be split into ekg-core and a compatibility library either, the upgrade path would be easy enough that you could just move the snap-specific functions into ekg-snap.
 
+Conrad Parker It took me a while to figure out what you meant by Kazu's webserver package, since he's been hacking on Warp for a long time now, and using it for mighttpd2. TIL about http://hackage.haskell.org/package/webserver.

I would say we should go for a WAI backend for ekg so it can be used by any WAI-based application, including Yesod. I'll go so far as to say that this should be included in the 1.2 Yesod release (https://github.com/yesodweb/yesod/issues/475).

Is the codebase stable enough that it would make sense to start hacking the WAI backend? Once it is, I'll email the Yesod mailing list and see if anyone wants to tackle this.

Also, a +1 for keeping `ekg` as a fully-functional package including a web server. If it uses Snap, Warp, or anything else, doesn't really matter to me, but I think it's the right approach to take.
 
+Nathan Howell It will greatly increase number of possible combinations of packages. And we have enough problems as it is. I think multiple packages are much cleaner and surprise free solution.
 
+Aleksey Khudyakov It would have the equivalent number of package combinations in practice, it's very rare/discouraged to require a flag be false. I think the spirit of the concept could be added to Cabal/Hackage without flags though, perhaps that would be easier to swallow.
 
+Nathan Howell packages that change their exposed API via flags are evil, and no right-thinking person should ever create one.
 
+John Millikin That's not the intent, I understand that particular issue. The idea is that a broader concept, like 'gzip' or 'lzma' or 'ekg' may have multiple implementations that operate depend on different set of packages. As a user I may want to say 'install all the gzip packages that work with my current set of packages', rather than having to go hunt for 'gzip-enum', 'iteratee-compress', 'zlib-conduit' and 'zlib', depending.
 
What I want to achieve with e.g. ekg-snap and ekg-yesod is a deep integration with those frameworks as e.g. snaplets or subsites. It's not just a question of a different implementation of ekg.
Add a comment...