I guess it depends on how you look at it, but I was using the Requests library (which uses HttpParser). So we wouldn't have to deal with the BinDeps issue explicitly, but it's still there.
I don't really care about the licensing, so making it Apache is no big deal to me. I'll write up my notes from talking to H2O as a first issue in the repo and the discussion can go from there. On Tuesday, November 17, 2015 at 10:30:10 AM UTC-5, Christof Stocker wrote: > > Funny coincidence. I have been playing around with its REST API > recently. I was thinking of mirroring the R package (and thus have a > more or less identical interface), which is Apache licensed and is > really nice to use. I did, however, have two concerns that discouraged > me. My main concern is the rapid pace of changes of H2O. I think that > even if you'd had a fully implemented H2O package that it would be quite > some work to keep it up to date. The second, more minor concern is that > I don't see a way of implementing the package without binary > dependencies, since HttpParser.jl introduces one. But this is more of a > personal preference of avoiding binary dependencies > > That being said, if you are really interested in doing this via the REST > API, then I am interested in contributing. I do think, though, that it > should be Apache licensed. Don't know if it makes a difference, but just > to be on the safe side. > > On 2015-11-17 16:04, Randy Zwitch wrote: > > I've been using H2O quite a bit at work, because it does a few things > > well (I mostly use it for random forest and GBM) and is easy to use. > > > > I talked with the company at length about creating a Julia package and > > the company is supportive of open-source contributions, so I created a > > stump of a package. Anyone interested in working on it with me? Right > > now, I'm still in between about using PyCall for everything or > > attacking the API directly. Anyone interested in helping can help me > > derive a development plan... > > > > https://github.com/randyzwitch/H2O.jl > >
