20:35:12 <dons> stepkut: any chance you guys can move to haxml 1.20.x ?
20:35:29 <dons> that's the stable release now, and most distros will probably move to it (Arch has)
20:52:21 <stepcut> dons: is the time right ?
20:52:40 <stepcut> dons: when we switched to QC2 it caused a bunch of issues because other things wanted QC1 still
20:52:49 <stepcut> we fixed that by not requiring QC at all..
20:53:10 <stepcut> I am not clear when the right time to pull the trigger is
20:53:21 <stepcut> maybe we should ifdef so you can use either ?
20:55:04 <dons> QC2 is ok (that's what the HP uses). Haxml moved from 1.13 to 1.20 about a year ago
20:55:10 <dons> maybe check what is in debian
20:55:25 <dons> as it is, i can't build happstack on arch using native packages (have to use cabal-install)
20:56:03 <stepcut> I'll add that to the 0.6 release
20:57:42 <stepcut> debian is still on 1.13 as far as I know
20:57:51 <stepcut> they tried to upgrade to 1.19, but then rolled back to 1.13
20:57:54 <stepcut> i think
20:58:11 <aavogt> this means that native packages need to be more flexible?
20:58:33 <stepcut> dunno
20:58:41 <stepcut> it means that people have not rushed to upgrade to 1.20 :)
20:59:30 <dons> 1.19 was an unstable version.
20:59:50 <dons> that was the problem. malcolm had two 'unstable' releases out simultaneously, for several years
20:59:55 <stepcut> right
21:00:24 <stepcut> well, he had the stable 1.13 release forever, and a lot of unstable releases, yes ?
21:00:44 <dons> yeah
21:01:12 <stepcut> the only thing holding us back from switching is not wanting to make things worse by upgrading too soon :)
21:02:38 <stepcut> I don't think we even really use HaXml. The happstack-data has it's own built in Xml type, and we provide the ability to convert that to HaXml :-/
21:02:54 <dons> seems like a huge dependency to add :/
21:03:10 <dons> pruning deps that could be optional, like that, might make life easier
21:03:10 <stepcut> not if HaXml is added to the HP :p
21:03:15 <dons> its GPLd
21:03:32 <stepcut> ah, we should really prune it then
21:03:34 <dons> so that might be tricky
21:03:44 <dons> LGPLd, sorry
21:03:59 <stepcut> ah
21:04:18 <stepcut> I am not sure anyway actually uses the xml stuff in happstack-data anyway, maybe we can split that whole part out
21:05:45 <stepcut> it was there so that you could have your server parts return some arbitrary haskell type, and then that type could be automatically turned into XML which you could turn into HTML via xslt
21:05:51 <stepcut> but no one is actually doing that AFAIK
21:06:06 <stepcut> also, it used to be used to serialize the checkpoints to disk, but now we use binary
21:06:40 <stepcut> however, it would still like to use it so that we can *export* the state as XML, in case you want to try to import it or analyze it in another system
21:07:01 <dons> maybe a lighter-weight xml package would be more sensible then.
21:07:14 <stepcut> anyway, it is officially on the roadmap now, http://code.google.com/p/happstack/wiki/RoadMap?ts=1275167105&updated=RoadMap
21:07:21 <stepcut> does HaXml have lots of dependencies ?
21:07:53 <dons> no, not really.
21:08:08 <stepcut> so what would be the advantage of a lighterweight XML library ?
21:08:20 <dons> oh, 4 modules to build instead of 84.
21:08:35 <stepcut> anyway, as I said, we don't actually use HaXml directly, so we could drop HaXml support and still do that stuff. You just won't get the functions to turn that internal Xml into HaXml
21:08:39 <dons> you don't use most of the haxml code, and distros have various incompatible versions, so perhaps you can get away with something 'lighter'
21:08:52 <stepcut> gotta run, going to drink more free wine and see the circus
21:08:56 <dons> yeah, what's the power/rate ratio for each dependency you add
21:09:09 <stepcut> well, I would say that supporting nothing would be better than lighter
21:09:18 <stepcut> the only reason to support HaXml is because it is common
21:09:25 <dons> ok
21:09:35 <stepcut> but, trimming dependencies is good right now
21:09:40 <stepcut> though troublesome
21:10:11 <stepcut> I want to add support for blazehtml to happstack, because it is much better than the current Text.(X)Html libraries. It is the best library of that type..
21:10:43 <stepcut> ideally I should add the support directly to happstack-server so that the ToMessage BlazeHtml instances is automatically in-scope
21:10:55 <stepcut> but then we have to depend on blazehtml, even if you don't want to use it (which is bad)
21:11:24 <stepcut> so I could put it in a new package, happstack-blazehtml, which is optional. But then you have orphan instances you have to remember to import (which is bad)
21:12:29 <stepcut> right now the ophan instance stuff is extra bad, because there is a, (Data a) => ToMessage a, instance. So if you forget to import Happstack.Server.BlazeHtml, instead of getting a sensible error message (aka, no instance for ToMessage BlazeHtml), you get a horrible 10+ line error message involving syb-with-class stuff
21:12:55 <stepcut> but, I am going to drop that instance because it does not bring any value.. no one actually uses it AFAIK, it just leads to broken code or horrible error messages
21:13:53 <stepcut> 0.6 is the 'break stuff in the name of simplicity' release where we fix all those types of issues, even if they might break some code (but probably not)
21:14:06 <stepcut> mostly I think people will just have to change a few imports, if anything
21:14:26 <stepcut> but I want to do it all at once so that people don't have to fix their code every release
21:14:28 <stepcut> that is the worst
21:19:18 <stepcut> and now I am stepping out the door