Hola Andy! Sorry if that email sounded bitchy. > Ooh, sorry about that. I've been spread a little thin recently. And the > hosting situation does suck a bit. On the other hand, I've been trying > to get another guile-lib maintainer for a while now -- you interested?
Well, I would be, except I'm spread a bit thin right now, too (working for a startup that's on the verge of a release). Plus, I don't know that I have a thorough enough understanding of Guile or Scheme to do the job effectively. I'd be happy to help out as much as I can, though. Is it possible to, uh, wrest control of the hosting situation? Or would it be better to start fresh with a new location / list? >> But it does raise the question of what the proper role for guile-lib >> is, given that no one seems to have touched it in more than a year. > > What do you want to do with it? > > A few different options come to mind: > > * Include (parts of?) it within Guile itself. This probably would > require copyright assignment, though perhaps not, if we put them > within a contrib/ section of the source distro (I would not want to > put `contrib' in the module name, however). > > * Make it a part of Guile, but not a part of the guile source > distribution. This way all Guile committers could administer it, and > perhaps it could just share the same mailing lists. I like that second option (although it doesn't do anything for cross-Scheme compatibility), and I'd imagine it'd go over better with Guile developers than making it part of Guile itself. >> Evan Prodromou's (net http) > > I haven't seen this code, but I want it! :) I think this is the most recent release: http://evan.prodromou.name/software/net-http/ >From what I can tell, it's no longer maintained (and as I remember was only partially complete), but even as a starting point for a real HTTP client implentation for Guile, you could do a lot worse. >> Another possibility is that the Snow project could meet this need, but >> there are some Guile-side technical hurdles to be jumped before it'd >> be viable -- and it's not like they don't have their own problems with >> bit-rot. > > Yes, and another option (parallel effort?) is to hack in support for > R6RS modules, and rely on other distributions. Hey, sure -- although we'd still need a way to locate modules. And could we actually rely on other distributions? My outsider impression is that there was a minor revolt when R6RS was passed (but maybe the library system was less offensive to people?). The only reason I suggested Snow was that it seemed, for whatever reason -- and however briefly -- to have a tiny bit of cross-platform traction. The R6RS library syntax ain't bad, though, now that I read the spec. I'll take a look at how hard it'd be to wedge it into Guile. >> It seems like other parts of Guile are being re-organized a bit right >> now -- any chance we could take a look at this as well? > > Let's make this situation suck less! Do you want to handle this? (Also, > it would be nice to move this code to git.) Well, I can make some suggestions! In addition to the above, maybe we could do a module-by-module audit of the current suite of code in guile-lib and see what the current state of each is -- i.e., whether it's compatible with Guile 1.8 / HEAD; if it's been superceded by code added to Guile core, etc. Would that be useful? Regards, Julian
