[Chicken-users] Re: ... and a happy new year as well!

[Ivan Shmakov]

>>>>> "NP" == Nicolas Pelletier <address@hidden> writes:
>>>>> "IS" == Ivan Shmakov <address@hidden>:

 IS> PS.  Currently, I'm about to begin my preparations for the course
 IS> on computer networks I'd be carrying on for the second time.  While
 IS> no part of the course the course has a specific focus on the
 IS> network programming, I'd be glad to hear any suggestions on how
 IS> Scheme (and functional programming in general) could be mentioned.

 NP> I'd suggest protocol analysis or traffic inspection. Chicken's
 NP> support for low-level access and easy ffi lets you hook almost
 NP> anywhere in the network stack.

        Does it?  The significant portion of the network stack is
        implemented in the kernels of the systems I know, and, IIUC,
        embedding Chicken into a (monolithic) kernel is unlike a clever
        idea.  (Though making Chicken capable of doing Hurd IPC may be
        interesting.  At the very least, it will allow implementing Hurd
        filesystem drivers in Scheme with much less the risk of crashing
        the whole system.)

        Although interferring with the kernel's own handling of the
        messages is possible (at least on GNU/Linux, thanks to, in
        particular, the TUN/TAP facility), it doesn't seem to be a thing
        that fits the time constraints of the course.  ... Or?

 NP> Then Scheme's power lets you use more advanced tools for analysis
 NP> (e.g. using a true parser to analyze a protocol, for example with
 NP> the packrat egg).

        Won't that require some introduction into parsing in general?

        The protocols with fixed-length headers are easier in that
        respect.  Does Chicken has easy support for these?

 NP> On top of that, you can hook some reasoning capabilities (for
 NP> example, with the kanren egg)

        Yet again, doesn't that imply some prior knowledge of the
        declarative programming?

 NP> to detect intrusions, attacks, questionnable traffic,

        These tasks seem to require fast response of the system.  Is
        kanren capable of that?

        Note also that, potentially, the program will have to be able to
        process up to tens of MiB per second in real-life
        configurations.  I'm in doubt that any implementation of a
        sufficiently sophisticated algorithm will fit the time
        constraints of the task.

 NP> or suggest an optimal network configuration, etc...

        ?

 NP> Or you can go for server-side programming, for example cgi,

        Do you mean writing CGI in Scheme?  Are there specific
        advantages over the other (high-level) languages?

 NP> connection pooling, access policy... or even (gasp!) cloud
 NP> computing (for example, cluster or cloud controllers);

        Well, to the extent I'm into this problem, I don't see anything
        to preclude the use of Scheme for that.  Moreover, there're some
        experiments that are being carried over here on distributed
        computing which may benefit of such software.  However, I don't
        see at the moment how this task may fit the course.

 NP> the kind of thing that is traditionally done in C with complicated
 NP> data structures, a lot of pointers, and no help from GC, closures,
 NP> or symbolic programming. And takes a lot of effort and money to
 NP> develop and debug :-)

        I guess that it's going to be a lot of effort to implement it in
        whatever language.  Or are there examples of the contrary?

 NP> Another hot topic today is the semantic web (RDF, OWL and friends).
 NP> This is an area where high-level languages with dynamic and
 NP> reasoning capabilities (e.g. Scheme, Lisp, Prolog, for example)
 NP> shine.

        Alas, I don't think I'm keen enough on these topics.

 NP> Whether you want to see the network from behind HTTP or not is up
 NP> to you, of course.

        I'm not sure about RDF, etc., but I've got a habit of thinking
        of XML separately from HTTP.  To my mind, both may be used (and,
        indeed, are used quite widely) independently of one another.

 NP> That's it for a few ideas.

        Thanks.

-- 
FSF associate member #7257

pgpGOFVjOB7Qz.pgp
Description: PGP signature