Thread: [caplisp-devel] httpsy porting
Status: Planning
Brought to you by:
radix42
Menu
▾
▴
caplisp-devel
|
From: James G. <an...@xn...> - 2005-09-27 04:30:14
|
As I mentioned over in e-lang, I've decided to switch gears and focus on
development based on Scheme 48. My posting policy will probably be as
follows:
e-lang
General discussion, policy issues, E-specific issues.
caplisp-devel
Implementation issues for CL and Scheme.
sch...@s4...
General discussion of Scheme 48 issues.
-----------------------------------------------------------
It looks like it will be a non-trivial amount of work to even get httpsy
ported to Scheme 48. Scheme isn't going to be as easy for a lot of this
stuff, in general. The libraries and applications aren't as well developed.
At any rate, I'm currently looking at SWIG support for Scheme 48. There
are already three other Schemes supported, so on the surface, adding
support for S48 shouldn't be too hard. As I have started getting into
this more, it looks like it might be quite challenging.
SWIG is being considered because S48 will need some kind of SSL support.
I'm leaning towards GNU TLS, but that's still quite open for discussion.
There's a fair amount of support for SSL in CL, so that shouldn't be a
problem.
After that, there's a web server to think about. Gotta have http,
before you have httpsy, right? There's a couple choices for CL,
Uncommon Web seems popular.
For Scheme, you've got the web server which comes with MzScheme, and
that's it. I don't consider the mod_NNN projects viable; I'm only
thinking about native implementations. The SISC server runs on top of
J2EE. So it isn't actually doing any actual http stuff itself.
And even for the MzScheme web server, it's got a fairly deep dependance
tree, and there seems to be a fair amount of infrastructure that will
need to be ported.
Huh. Just ran across "spiffy" which is for Chicken Scheme. Seems
fairly small in compairison.
But porting stuff _from_ MzScheme couldn't be easier... in a sense. The
DrScheme enviroment as a nice source and module browser. It even draws
dependancy graphs.
Guess we'll have to see how small Spiffy is, and if it is worth the bother.
James Graves
|
|
From: James G. <an...@xn...> - 2005-09-27 22:41:13
|
I got the good word from the Scheme 48 folks. I'm not going to bother with SWIG at this point. It would be difficult to add support for another target. In fact, though I thought it was the case, there is no support in SWIG for any CL implementation either. :-( So we've got some other tools to do the FFI generation for OpenSSL and/or GNU TLS. I'm only going to need a small part of the API to begin with anyway. I'm also tempted to work on some kind of tool to automatically convert modules for other Schemes (most notably Chicken and DrScheme) to make it easier to import their libraries. I'll need to hand-convert a few first, to get a good feel for what that would require. Cheers, James Graves |
|
From: David M. <ra...@gm...> - 2005-10-09 03:10:33
|
Sorry for the very delayed replay, 3 math classes at once has been more of a load than I thought it would! Comments interspersed below.=20 -David Mercer On 9/27/05, James Graves <an...@xn...> wrote: > > I got the good word from the Scheme 48 folks. I'm not going to bother > with SWIG at this point. It would be difficult to add support for > another target. In fact, though I thought it was the case, there is no > support in SWIG for any CL implementation either. :-( I'm actually kinda glad you're back to s48 for your efforts, as that's a direction I'd wanted to explore for a while, too. Even emailed jar about some things regarding such an effort a time or two. I punted to image level confinement in my current caplisp aspirations for pretty much the reasons jar outlined in very good detail in your message (on elang I think) recently. Or at least a decent subset of them! > So we've got some other tools to do the FFI generation for OpenSSL > and/or GNU TLS. I'm only going to need a small part of the API to begin > with anyway. That sounds like a great place to start. > I'm also tempted to work on some kind of tool to automatically convert > modules for other Schemes (most notably Chicken and DrScheme) to make it > easier to import their libraries. I'll need to hand-convert a few > first, to get a good feel for what that would require. Oh such a tool would be very, very sweet! I'd actually started a reply to your longish email I referred to above, but realized it would be mostly just "yes, I agree" type statements; hence this one instead. I'm very interested to follow any/all progress you make with s48. Let us all know when there's code to look at! Cheers, David Mercer Tucson, AZ |
|
From: James G. <an...@xn...> - 2005-10-09 23:33:57
|
David Mercer wrote: > Sorry for the very delayed replay, 3 math classes at once has been > more of a load than I thought it would! Comments interspersed below. Yeah, well, having a 60+ hour a week day job also isn't conducive to working on free software in my free time either. > I'm actually kinda glad you're back to s48 for your efforts, as that's > a direction I'd wanted to explore for a while, too. Even emailed jar > about some things regarding such an effort a time or two. I punted > to image level confinement in my current caplisp aspirations for > pretty much the reasons jar outlined in very good detail in your > message (on elang I think) recently. Or at least a decent subset of > them! If there's anything interesting/useful that he or you said, please forword it if you can get permission. >>So we've got some other tools to do the FFI generation for OpenSSL >>and/or GNU TLS. I'm only going to need a small part of the API to begin >>with anyway. > > That sounds like a great place to start. I haven't made much progress lately. I did get Scheffig up and running, and that stuff is detailed on the Scheme 48 mailing list. However, I've continued to run into problems with it, and until I spend some more time studying it, I'm putting Scheffig on the shelf for now. This was also prompted because the existing socket library for Scheme 48 doesn't expose the Unix file descriptors, just Scheme ports. Whereas OpenSSL (*) expects to be handed Unix file descriptors, and it makes the SSL connection on top of that. So I'll need to create some wrapper functions which can extract the Unix file descriptor (easy). And then we'll also want to create a Scheme-ish port interface on top of that. (also not hard) That's probably about a day's work total. What is inconvenient though, is that there are plans to re-vamp the network programming library for Scheme 48, as part of a possible re-unification with SCSH (**). I'm thinking I just want to create the minimal possible interface to OpenSSL, and then wait to see what happens with the networking API. >>I'm also tempted to work on some kind of tool to automatically convert >>modules for other Schemes (most notably Chicken and DrScheme) to make it >>easier to import their libraries. I'll need to hand-convert a few >>first, to get a good feel for what that would require. > > > Oh such a tool would be very, very sweet! Yeah, but it will be a fair amount of work. Perhaps it would be better to support the "Common Scheme" effort, and try to get people to port their libraries to that instead. > I'm very interested to follow any/all progress you make with s48. Let > us all know when there's code to look at! Will do. James Graves (*) I started first working with GNU TLS. I downloaded their documentation page, and started trying to compile the example code. This didn't work for a couple reasons: missing functions (which I could easily have fixed) and that all the structure names have changed between version 1.0.x and version 1.2.x. The documentation refers to 1.2, and I have 1.0 installed on my Debian Sarge machines. I could download and install 1.2, and then point the compiler and linker at the new version, but I didn't want to futz with it. Meanwhile, I found some 9 year old demo code for OpenSSL, and after a few very minor tweaks, it compiled, ran, and appears to function correctly. Huzzah for stable APIs! Defintely using OpenSSL for now, despite the license issues. (**) So in this case, Scheme 48 is the Vulcans, and SCSH is the Romulans. |
Thanks for helping keep SourceForge clean.
X