[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
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
- [h-e-w] gnuserv maintenance, Matthew X. Economou, 2004/10/26
- RE: [h-e-w] gnuserv maintenance, Horsley Tom, 2004/10/26
- RE: [h-e-w] gnuserv maintenance, Windhorn, Allen, E. [LS/MKT], 2004/10/26
- RE: [h-e-w] gnuserv maintenance, Matthew X. Economou, 2004/10/26
- RE: [h-e-w] gnuserv maintenance, Matthew X. Economou, 2004/10/26
- RE: [h-e-w] gnuserv maintenance, Dalton, Barnaby, 2004/10/26
- Re: [h-e-w] gnuserv maintenance, Richard M. Heiberger, 2004/10/26