Updating GNU Serveez for Guile 2.0

Updating GNU Serveez for Guile 2.0

[Mike Gran]

Hi-

With some trepidation, I've decided to announce a beta release of a
project I've been working on, which, for now, I'm calling
serveez-mg.  (Release early, release often, right?)

serveez-mg is a framework for writing servers in Guile.  It
implements a server framework where you only have to write callback
functions that respond to server requests.  It takes care of 
the main server poll loop and low-level socket connection functions.

serveez-mg takes the form of a compiled executable than can run as
a daemon.  It uses Guile as an extension language to describe servers.

The guts of serveez-mg come from the GNU serveez software, which is
a much grander project that attempts to demonstrate how to write
server software in many different platforms and protocols, including
W32.  So, I've stripped GNU serveez just to its Guile and GNU/Linux
parts, and thenupdated them to work with Guile 2.0.

There's a download server and git repo you can browse at

  https://github.com/spk121/serveez-mg

And some documentation you can read at

  https://github.com/spk121/serveez-mg/raw/master/doc/serveez-mg.txt

The original GNU Serveez project (which should work with Guile 1.4) 
can be found at

  http://www.gnu.org/software/serveez

Thanks,

Mike Gran

Re: Updating GNU Serveez for Guile 2.0

[Ludovic Courtès]

Hello Mike!

Mike Gran <spk121@yahoo.com> writes:

> There's a download server and git repo you can browse at
>
>   https://github.com/spk121/serveez-mg
>
> And some documentation you can read at
>
>   https://github.com/spk121/serveez-mg/raw/master/doc/serveez-mg.txt

Great, looks like a nice plan!

I just read the bits about the DNS co-server.  Recently I was thinking
we should have a higher-level API for domain name resolution in Guile,
which would (1) be more Schemey and more portable than the ‘getaddrinfo’
procedure, and (2) support asynchronous requests using a future-like API
with a dedicated thread pool.

So perhaps parts of the Serveez spirit could conquer Guile core?  :-)
Thoughts?

Thanks,
Ludo’.

Re: Updating GNU Serveez for Guile 2.0

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Sun, 23 Jan 2011 22:46:59 +0100

   So perhaps parts of the Serveez spirit could conquer Guile core?  :-)
   Thoughts?

I don't think this is a good idea, for the same reason i don't think (web ...)
modules are a good idea; it centralizes non-language implementation stuff into
the language implementation.

Moreover, Guile is LGPL while the stuff outside is GPL, which is a stronger
protection for the user.  Every time GPL is relaxed to LGPL, i consider that
to be a step backward.

Re: Updating GNU Serveez for Guile 2.0

[Mike Gran]

> From:Thien-Thi Nguyen <ttn@gnuvola.org>

> 
>    So perhaps parts of the Serveez spirit could conquer Guile core?  :-)
>    Thoughts?

I've been playing in own sandbox for a while.  I've lost touch with what
guile-core and guile-www provide.  But, I agree that some of those POSIX-style
APIs are klunky.

(I hesitated at announcing the project because I felt bad about not instead
focusing my effort on using (web ...) and guile-www.  But it did come out
rather nice, I think.)

> I don't think this is a good idea, for the same reason i don't think 
> (web ...)
> modules are a good idea; it centralizes non-language implementation stuff into
> the language implementation.

I weakly agree with this statement.  But I think that if a language doesn't have 
a LAMP-like stack, it is missing an opportunity to be useful.  So I somewhat
agree web stuff doesn't need to be *in* the language but it certainly needs to
be *nearby* the language (whatever that means). 

OTOH, pure scheme scripts don't take up a lot of space.

> Moreover, Guile is LGPL while the stuff outside is GPL, which is a stronger
> protection for the user.  Every time GPL is relaxed to LGPL, i consider that
> to be a step backward.

This is a valid point.  Serveez is GPL 2+.

Thanks,

Mike

Re: Updating GNU Serveez for Guile 2.0

[Ludovic Courtès]

Hello!

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () ludo@gnu.org (Ludovic Courtès)
> () Sun, 23 Jan 2011 22:46:59 +0100
>
>    So perhaps parts of the Serveez spirit could conquer Guile core?  :-)
>    Thoughts?
>
> I don't think this is a good idea, for the same reason i don't think (web ...)
> modules are a good idea; it centralizes non-language implementation stuff into
> the language implementation.

I was just referring to the asynchronous ‘getaddrinfo’ stuff, not to all
of Serveez.

I think it’s an important building block when writing an application,
just like Glibc has ‘getaddrinfo_a’, so my feeling is that making such
tools part of Guile core can make it easier for people to develop
applications in Guile.  The same holds for the web and SXML tools, IMO.

> Moreover, Guile is LGPL while the stuff outside is GPL, which is a stronger
> protection for the user.  Every time GPL is relaxed to LGPL, i consider that
> to be a step backward.

Agreed.

In principle, I’d be happy to incorporate such tools under the GPL in
core Guile.  The only downside I can think of is possible user confusion
if there’s both LGPL and GPL code in Guile, though it could be solved
technically (e.g., by adding a special ‘define-module’ clause for GPL
modules.)

GnuTLS, has the main lib under the LGPL and an “extra” lib with special
features under the GPL (info "(gnutls) GnuTLS-extra functions"), which
seems like a viable option.

Thanks,
Ludo’.

Re: Updating GNU Serveez for Guile 2.0

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Mon, 24 Jan 2011 16:13:59 +0100

   I was just referring to the asynchronous ‘getaddrinfo’ stuff,
   not to all of Serveez.

Ah, why didn't you say so in the first place?  No objections there.

Re: Updating GNU Serveez for Guile 2.0

[Ludovic Courtès]

Hey,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () ludo@gnu.org (Ludovic Courtès)
> () Mon, 24 Jan 2011 16:13:59 +0100
>
>    I was just referring to the asynchronous ‘getaddrinfo’ stuff,
>    not to all of Serveez.
>
> Ah, why didn't you say so in the first place?  No objections there.

I thought I did mention it, sorry for the confusion.

Ludo’.