|
Subject: (usagi-users 03517) Porting SUnet to s48; network API convergance Newsgroups: gmane.linux.ipv6.usagi.users, gmane.lisp.scheme.scsh.devel Date: 2005-10-07 10:38:19 GMT (3 years, 38 weeks, 5 days, 15 hours and 38 minutes ago) Hi! Since I'd like to be able to run SUnet on Scheme48, I have wondered what the best way would be to achive this; here are excerpts of my exchange with Michael Sperber: ,---- | Andreas Rottmann <ar <at> visotech.at> writes: | | > [...] These ideas and patches are all somewhat related to the effort | > of porting scsh to Scheme48. I'm also interested in details on that, | > since I want to have SUnet available for Scheme48 and that would | > mean porting some scsh libraries/infrastructure. Could you please | > point me to information on the porting process, so I can get | > involved? | | That's a handful of questions. I'm not sure I can answer all of them | well: | | The general plan with scsh and Scheme 48 is to clean up the scsh APIs | one by one. The network API is high on that list, and indeed running | SUnet on Scheme 48 is among our plans. For that to happen, what we | need to do is overhaul the scsh networking API---to clean it up, and | to fit better with Scheme 48 conventions. First and foremost, that | means turning the enumerations into finite types, I think. The best | way to do it is probably to make the changes on the scsh trunk, and, | when the code is ready there, merge it over. (We also have plans to | coordinate the network API with the PLT people, but that's probably a | bit further off.) So, if you want to help, submitting patches to scsh | (coordinating with the scsh-hackers list) would probably be the | appropriate first step. `---- So, as a first step, I'm posting this here as a heads-up, and to ask wether any efforts in that direction have already been undertaken or are planned. FWIW, I've created an GNU Arch archive corresponding to the scsh CVS trunk, and will branch from that, since CVS branching/merging is mostly unusable. As Michael Sperber already indicated, a first change will be converting the network constants (e.g. protocol-family/*) to finite types. Since currently these constants are hardcoded to match the constants used in the corresponding C API, my idea was to have a platform-specific mapping procedure, e.g. PROTOCOL- |
|
|