[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] gnuserv maintenance

From: Guy Gascoigne-Piggford
Subject: Re: [h-e-w] gnuserv maintenance
Date: Wed, 27 Oct 2004 20:01:10 -0700
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Wow, what a lot of email on this subject :-)

So here's my take on this.

First, I'm the person who put together the version of gnuserve at, I didn't write the original version, but I did do quite a bit of the porting to make the NT version more completely compatible with the Unix version. At one point in the distant past I actually knew the code pretty well :)

Secondly there is quite an irony in this subject coming up here about three days after a similar discussion started in the emacs-devel list.

Obviously pretty much anything on the emacs-devel list is focused on future versions of emacs so there is a bit of a split of interests. emacs-devel is looking at how best to fold in enough gnuclient style functionality into emacs that we no longer need gnuclient. Emacs has always had a similar program called emacsclient which in the past has been very limited hence the development of gnuclient/gnuserv, more to the point emacsclient has never been ported to NT.

I can't say for sure exactly how the emacsclient support will look in emacs 21.4 (I think that's the next version) since I've only just got involved in it, but I'm time willing we should get it working in a way that keeps people happy.

That doesn't really deal with the issue of fixing some of the problems with the existing version of gnuserve for existing versions of emacs, and none of this deals with the fact that the XEmacs folks have taken the gnuserve code and run with it, changing it into something quite different and fairly incompatible with the version that I worked on (it actually looked pretty cool last time I looked).

As for maintaining it I have to say that I've been pretty lame at it, I've tried to answer what support email I get (which is still one or two a month, not bad for something I last uploaded 4 years ago), but on the whole I've never seen the need to change it based on what I've seen. Clearly that's not really the case.

As for maintaining gnuserve. I'm pretty happy to go either way on this. I'll carry on doing this, or I'll let someone else. Either way I'll happily make the link on my site point to the "currently maintained version".

Anyway, on to your points:

Matthew X. Economou wrote:

The sockets version of the gnuserv port to NT currently has no maintainer.  The 
version posted at is several years 
old, Edi Weitz does not have time to maintain the version on his web site 
(understandably enough), and no one has updated the port for Visual Studio 
.NET.  Unless anyone raises an objection, I will take over gnuserv's 
maintenance.  I plan on fixing the following bugs:
I need to take a look at Edi's patches, I'd not seen them before, superficially they look reasonable, I guess I just don't run that many maximized apps :)

Making it work with Visual Studio .NET ought to be pretty easy (even though I still rather prefer VC6), but to be honest making it work correctly with mingw is probably just as important.

(1) gnuclientw exits immediately after sending the file to Emacs, i.e. "-q" is 
always set.

This flaw is shared by the mailslots version of gnuserv/NT.  Apparently, the original 
porter defined "-q" to always be active for the Win32 application version of 
gnuclient.  This breaks programs such as the Zope ExternalEditor client which wait for 
the child editor process to exit before performing some function (i.e. the gnuclientw 
process exits immediately so the caller thinks nothing was edited).
Can't you just use gnuclient and not gnuclientw? But it would be easy to work around this and add a +q or the like.

(2) The connection between gnuclient/gnuclientw and gnuserv closes after 300 

Exactly 300 seconds after gnuclient sends a file to gnuserv, the socket 
connection closes and gnuclient exits.  I do not yet know why this happens.  
The mailslot version does not exhibit this flaw.  Again, this breaks programs 
that wait for the editor sub-process to exit before performing some function on 
the edited file, e.g. ExternalEditor.
This is just the way that gnuclient worked when I ported it, and yes, it can be a bit annoying.

I plan on making the following changes:

(1) Update the sources to build on Visual Studio .NET.

I don't want to bother with (a) finding my VC6 discs or (b) converting the 
project every time I open it.  Besides, it's time to lay VC6 to rest.

(2) Merge the mailslot version.

(I don't know if there is a maintainer for the mailslot version of gnuserv.  I 
also don't purport to understand how the mailslot version works.)

Since not every Windows computer is a single-user workstation, and since I 
don't want to tackle the problem of authenticating and securing the socket 
connections (which requires changes to the Unix version of gnuserv), I would 
like to, at some point, merge the socket and mailslot versions of gnuserv, so 
users have the option of running a version of gnuserv that cannot be accessed 
over the network or loopback interfaces.
Agreed, I think that this would probably be a very good idea. Whilst I really like the IP version and work back and forth between my NT box and my Linux one using remote editing sessions and ange-ftp, I do realise that most people never need this and don't really want to pay the price for it.

I don't think that there is anyone maintaining the mailslot version, though I do still have source for it around somewhere.

(3) Put everything under CVS.

I am a version control freak.

(4) Set up an issue tracker.

I have a Plone site that I could use, or I could set up bugzilla or something 
else.  Maybe I'll host this all on Sourceforge or something.

(5) Re-write the gnuserv documentation.

Two out of date readme files, the old Unix man page, and a crufty HTML copy of 
the man page do not quality documentation make.  A couple hundred lines of 
generally uncommented source code are not documentation either.

I have no schedule for any of this, but if you have some changes you want made, 
just email me or post here and I will do my best.
The docs are very poor and can surely be improved.  No argument there.

Anyway, as I said, I'm happy to be involved in this (and to be honest suspect that it would be a good idea). Now I guess I should trawl through this thread and see what else I've missed :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]