Re: [h-e-w] gnuserv maintenance

[Guy Gascoigne-Piggford]

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  
http://www.wyrdrune.com/Files/gnuserv.zip, 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 http://www.wyrdrune.com/Files/gnuserv.zip 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 
> seconds.
>
> 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 :)

Guy