--- Log opened Wed Mar 25 00:00:54 2009
06:46 < koeien> do we want crypto built-in or using dependencies ?
12:02 < koeien> i was wondering; should we include hash functions and other crypto stuff in happstack, or leave it out?
12:03 < koeien> this generalizes, should we prefer to depend on external libraries or copy our own
12:08 < wchogg> Personally I lean towards outsourcing as much as possible.
12:11 < koeien> wchogg: perhaps you are correct. however in that case we should pay close attention to the version numbers we require. we also become more sensitive to external bugs (but also they get fixed faster)
12:13 < wchogg> koeien : Right.  Those are real caveats, but I think maintaining less code will in the end pay off.
12:14 < koeien> wchogg: i agree; the MD5 case was telling imho
12:25 < mae_work> koeien, wchogg: external deps yes, maintain crypto/sha stuff ourselves no
12:25 < mae_work> restrict the cabal version a bit
12:25 < mae_work> to avoid moving target bugs
12:25 < koeien> in that case we should remove SHA1, MD5, et al
12:26 < mae_work> ok question
12:26 < mae_work> what internally in server or state depends on sha md5 etc
12:26 < mae_work> as i understand it this was a licensing issue with alex
12:26 < mae_work> i personally don't care, but having everything bsd compatible is good
12:26 < mae_work> sha and puremd5 both meet this requirement
12:26 < koeien> yes
12:27 < wchogg> Yeah, the liscensing problem was just that the RSA part of Crypto was GPL.  I still don't think that would have been a problem, but ianal
12:27 < mae_work> I would also like to see ixset split off as its own deal
12:27 < mae_work> i.e Data.IxSet
12:27 < koeien> wchogg: ah, RSA. why would happstack need RSA ?
12:27 < wchogg> koeien : I have no idea, but that was the only part of Crypto that was GPL & apparently that scared Alex off.
12:27 < koeien> i mean, some apps use some crypto, but they can import it themselves
12:28 < mae_work> i think creighton is trying to switch the licensing
12:28 < mae_work> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto-4.2.0
12:28 < mae_work> what is OtherLicense
12:28 < mae_work> if we are not using crypto internally, then i see no reason to worry about licensing
12:28 < mae_work> we should deprecate those
12:28 < wchogg> If you look in the package the license is a delineation of what parts are BSD3 & what parts are GPL
12:28 < koeien> mae_work: probably because of the mixed licensing
12:28 < wchogg> It's a little weird
12:29 < koeien> i seee a file SHA1.hs that is BSD-licensed
12:29 < wchogg> Also, Crypto is a little outclassed at the moment in speed since it's not at all bytestring based.  This is something I'm currently working on, but it's a bit slow.
12:30 < mae_work> wchogg: ok, well lets move towards splitting that off
12:30 < koeien> it's trivial to write an incorrect / vulnerable RSA implementation. why not use OpenSSL ?
12:30 < mae_work> anyone want to be the dictator of the ixset stuff?
12:30 < koeien> IANACryptographer
12:30 < mae_work> we can split this off into a hackage package
12:30 < mae_work> change Happstack namespace to Data.IxSet so it can be more widely adopted
12:30 < koeien> isn't ixset already split off into happstack-ixset ?
12:30 < mae_work> well yeah
12:31 < mae_work> i mean, outside of the happstack umbrella
12:31 < wchogg> Honestly, I might like to be the Dictator of ixsets.  There's a lot of things I want to add to it, and I'd be less timid if it wasn't a part of the main happstack
12:31 < koeien> it depends on -data & -util now
12:31 < mae_work> its mature enough to work as is, and I think someone who is  interested in developing a data library like that should take ownership of it
12:31 < wchogg> It only depends on data because of serialize & version instances
12:32 < mae_work> yeah it depends on -data because it includes a definition for an instance of Serializable
12:32 < mae_work> yep
12:32 < koeien> that can be moved to -data then
12:32 < mae_work> i would tend to agree
12:32 < mae_work> that is fine right now
12:32 < mae_work> but if someone wants to improve and own that library more, I would like to see it split off
12:34 < mae_work> wchogg: are you interested? you seem like a fairly busy guy so if its gonna burn you out then don't do it :)
12:34 < koeien> and in that case we can depend on external SHA-1 / MD5 / SHA-2 if necessary; i don't see where we need that
12:35 < mae_work> koeien: yep, i agree, the only reason we have it is for the historical licensing issues, which I personally see as non-issues
12:35 < mae_work> although it sounds like they support bytestring and wchogg is working on adding this to the crypto lib
12:35 < koeien> i don't agree with the characterization as "non-issues"; but we have it because alex needed it and didn't want Crypto ?
12:36 < wchogg> Right, but at this point there are bytestring based external libraries that fill most/(all?) of the functionality alex put into Happstack.Crypto
12:36 < mae_work> koeien: by non-issues I mean, non-issues for me.
12:36 < wchogg> that are all BSD3
12:37 < koeien> wchogg: yes, at least for the stuff i needed (SHA-x)
12:37 < koeien> we could compile a list, but that's not really necessary
12:37 < mae_work> the gpl AFAIK allows you to use the library for your own internal projects, as long as you don't intend to distribute the binary (and if you do distribute the binary you have to include the source)
12:38 < mae_work> webapps are kind of in a gray area in that sense
12:38 < koeien> mae_work: i don't see why it's a "grey area", but ianal.
12:38 < gwern> yeah, that's the tivo hole in essence
12:38 < koeien> that's why the AGPL exists
12:38 < gwern> affero plugs it ho
12:39 < koeien> mae_work: yes, but i think happstack = BSD3 is a requirement ?
12:39 < mae_work> verbatim: The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.
12:39 < koeien> since ghc's library afaik doesn't throw away the GPL bits, you technically might have to GPL your program if you include Crypto/RSA (IANAL)
12:39 < mae_work> from http://www.fsf.org/licensing/licenses/agpl-3.0.html
12:40 < mae_work> koeien: only if you try to distribute it
12:40 < koeien> mae_work: of course! but why limit it
12:40 < koeien> it could be a nasty surprise
12:40 < mae_work> koeien: i agree, but i am weighing the licensing issue against the practical matter of maintaining an entire crypto suite
12:41 < mae_work> for webapps (happstack 90% use case) it is not going to cause any problems
12:41 < koeien> anyway, i think we all agree that users should use external libraries for this
12:41 < mae_work> unless you try to distribute it
12:41 < koeien> mae_work: i think distributing might happen
12:41 < mae_work> koeien: then that is not our problem
12:41 < mae_work> the licensing issues are in the hands of the implementer
12:41 < koeien> mae_work: you are saying, this is "BSD", but in fact it is not
12:41 < mae_work> since it is an external lib
12:41 < mae_work> as you said :)
12:41 < koeien> yes, i know, alex solved it
12:42 < mae_work> koeien: how am I saying that this is BSD?
12:42 < koeien> but does happstack use MD5 or friends?
12:42 < koeien> mae_work: hypothetically speaking, n/m
12:42 < mae_work> koeien: i am not sure if it does, but I believe puremd5 and sha1 are both bsd3, so we can be fully bsd3 compliant :)
12:43 < mae_work> but if crypto needs to be used, then that is not our problem, and not used internally
12:43 < koeien> yes, both are BSD3. also the SHA-library i ported is BSD3
12:43 < mae_work> i think creighton might still be able to get that lib fully bsd3 yet..
12:43 < koeien> even in that case, why would we include it?
12:43 < mae_work> koeien: i think we are in violent agreement, we don't include it, we just remove it, and point whiners to hackage crypto
12:44 < koeien> agreed
12:44 < mae_work> question is when
12:44 < mae_work> is there anything that Happstack.Crypto does that hackage crypto can't do? (licensing issues aside)
12:44 < mae_work> afk for a min
12:45 < koeien> a grep doesn't show any imports of the Crypto stuff
12:46 < koeien> whoops, i am completely wrong. SimpleHTTP uses Base64, Server.S3 uses HMAC, Facebook uses MD5
12:49 < mae_work> hm
12:49 < mae_work> now hold on a minute
12:49 < mae_work> what is wrong with directly importing external packages inside of Happstack (not re-exporting and claiming to be BSD3)
12:50 < koeien> nothing. as long as the package is BSD3
12:50 < mae_work> um
12:50 < mae_work> what if it is gpl
12:50 < koeien> then end-users have a problem
12:50 < mae_work> the happstack project can still claim to be bsd3
12:50 < koeien> no it cannot, you just made a 'derivative work'
12:50 < mae_work> end-users with redistribution needs
12:51 < mae_work> but heres the thing
12:51 < mae_work> how do you know that we don't already depend on a gpl package somewhere down the line?
12:51 < mae_work> deps of deps
12:51 < mae_work> several layers deep
12:51 < mae_work> we have alot of dependencies
12:51 < koeien> this could be, in theory.
12:51 < koeien> in that case we have a problem
12:51 < mae_work> we don't have a problem
12:51 < mae_work> redistributors have a problem
12:52 < koeien> most Haskell software on Hackage is BSD-licensed afaik
12:52 < koeien> yes, redistributors have a potential problem, but they should be aware of it
12:52 < koeien> *if* it was the case
12:52 < mae_work> and again, not for the webapp use case
12:53 < koeien> true, but what if you want to give your client a server with your app installed?
12:53 < koeien> that counts as "distribution"
12:53 < mae_work> i'm not saying your point is not valid
12:53 < mae_work> i'm just saying that we don't have alot of control over external libraries
12:53 < mae_work> alex took the extreme reinventing the wheel for this very reason i think
12:54 < mae_work> he wanted all to be bsd flexible
12:54 < mae_work> I think if someone runs into a problem like this, then the underlying libraries can be replaced as it comes up
12:54 < mae_work> right now it is just an impedance to progress
12:54 < koeien> yes. but we shouldn't include MD5 / SHA-1, they are packaged on Hackage. we should depend on pureMD5 instead ourselves
12:55 < koeien> (for Facebook)
12:55 < koeien> i don't know if there is a Base64 library, there probably is - let me check
12:55 < mae_work> ok
12:55 < koeien> there is, base64-string, only for String the description says
12:56 < koeien> (we use that for HTTP authentication)
12:56 < mae_work> do we have to use it?
12:57 < koeien> i guess so, if we want to support HTTP-authentication
12:58 < koeien> ah, but SimpleHTTP only uses base64 for strings. so we can use the Hackage package
12:59 < mae_work> yeah http-auth isn't heavy in terms of # of bytes sent
12:59 < mae_work> no big deal
12:59 < koeien> sure, it's just a signature
13:00 < mae_work> I would love to see some patches
13:00 < mae_work> to make it in before 0.3 (april 4)
13:00 < koeien> i probably have some time this weekend
13:01 < mae_work> allright
13:01 < koeien> the only thing that is left is HMAC, for which there is no separate package on Hackage
13:01 < koeien> used by Server.S3
13:01 < mae_work> ic
13:01 < mae_work> well change what we can now, and eventually we will sever all ties and can drop it
13:02 < koeien> yes. we should hide it anyway
13:02 < koeien> or mark it deprecated
13:02 < mae_work> again, patches are welcome :)
13:02 < mae_work> so much work to do, so little time
13:02 < mae_work> i'm polishing up this auto-recompile bit
13:02 < koeien> ah yes
13:03 < mae_work> not nearly as advanced as stepcut/saizans idea, but as I am waiting for an implementation to materialize, this works good enough for now.
13:03 < koeien> what is the problem with just some shell script?
13:03 < mae_work> thats basically what i'm doing
13:03 < koeien> portability, i guess
13:03 < mae_work> i'm using the same method that searchpath does
13:03 < mae_work> but generalizing it
13:04 < mae_work> basically it will be a command
13:04 < mae_work> something along the lines of
13:04 < koeien> what latexmk is for latex ?
13:04 < mae_work> happstack-autorebuild <buildcmd> <targetexe> [<targetargs>]
13:04 < mae_work> so in practice if you cabalize your project
13:04 < mae_work> this would be
13:05 < mae_work> happstack-autorebuild "cabal configure && cabal build" dist/build/myapp/myapp
13:05 < koeien> and for windows?
13:05 < koeien> not that i use that of cour4se ;)
13:05 < mae_work> cabal does the heavy lifting (recompilation checker) to see if any modules need to be rebuilt, and if the binary is built, it kills and restarts after the new bin is built
13:05 < mae_work> that will work on windows
13:05 < koeien> the && does?
13:06 < mae_work> yes
13:06 < koeien> cool
13:06 < mae_work> the windows cmd shell supports that
13:06 < koeien> my lack of windows knowledge shines through
13:06 < mae_work> heh
13:06 < mae_work> well, like i said, i would love to see some patches for cleanup of that stuff
13:07 < mae_work> gotta run right now
13:07 < mae_work> ttyl
20:37 < mightybyte> Does anyone have experience doing data migrations in happstack?
20:37 < stepcut> mightybyte: I do
20:55 < mightybyte> I'm wondering what the best practices are for code organization.
20:55 < stepcut> mightybyte: still working on that :)
20:55 < mightybyte> It seems like that is a significant issue.
20:56 < stepcut> mightybyte: I wrote a little bit here, http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
20:56 < stepcut> mightybyte: but it does not cover the issues that happstack-state adds to the picture
20:57 < stepcut> mightybyte: one of the issues that needs to be addressed for code organization is making sure the policy makes it clear when you need to add new migration instances
20:57 < mightybyte> Yeah
20:57 < stepcut> the policy I outlined does that, but it makes it hard to see all your types in one place then
20:58 < mightybyte> My state has a rather complex structure, so I'm thinking I need to be careful about this.
20:58 < stepcut> hrm... maybe a comment in the code would do the trick
20:58 < stepcut> i'll have to map that out and see
--- Log closed Thu Mar 26 00:00:56 2009