Fwd: status of slrn

"John E. Davis" <[email protected]>
Newsgroups gmane.network.slrn.user
Message-ID <[email protected]>
[This message was posted several days ago to news.software.readers.  I
 was asked to forward it to the slrn-users mailing list.]

Hello,

As some of you already know, a number of years ago I asked Thomas
Schultz if he would like to take over as lead developer of slrn.  I
chose Thomas for this role because it was clear from the patches that
he sent me that he had a good understanding of the internals of slrn.
I think that most would agree that he was a good choice and that he
has done a great job in this role, and as such deserves a big
"Thank-You" from all slrn users.

As Thomas no longer has time for the development of slrn, a couple of
weeks ago he asked me if I would like to again assume the
responsibility of slrn's lead developer. Although, with the exception
of the slang-2 patches, I had not worked with slrn source code for a
number of years, I accepted his offer.  I did so for a couple of
reasons.

First of all, I use slrn on a daily basis to keep up with a number of
mailing-lists.  But, as you can see from my previous postings, that
version of slrn is 0.9.6.4, which dates from about 2000, and requires
slang-1.  A slang-2-based slrn would mean that I would no longer have
to drag slang-1 around.  I did not consider upgrading to a new version
of slrn as an option since a slang-2 version was never released.  By
becoming an active developer, I would be forced to upgrade.

I am also the primary developer of the jed text editor, which has a
lot in common with slrn, e.g., it also makes extensive use of slang
(more than slrn, in fact).  More to the point, I want to provide jed
with better support for multiple character-set encodings using, e.g.,
iconv.  It is my hope that the experience I gain from working with the
character-set code in slrn will simplify the job of adding such
support to jed.

I have been working with the latest development version of the slrn
source code for the past two weekends.  In fact, if you look at the
headers of this post, you will see that I am using slrn "pre-0.9.9".
As the version suggests, the next official release will be 0.9.9.  It
is unclear at this point exactly what will be in that version.

Right now I am re-acquainting myself with the slrn source code by
cleaning up and simplifying various parts of the code, and fixing any
(potential) bugs that I see.  I have also removed the dependence on
automake.  I would like to support other operating systems such as
windows via the mingw32 compiler, and I find it simpler to do so by not
having automake in the way.  

I plan to pull much of the mime and character-set code out of slrn and
rewrite it in slang.  As it is far easier to deal with strings in the
interpreter than it is in C, I believe that this will make the code
more robust, and much, much simpler to maintain.  The idea is that when
slrn starts up, it will read some file, e.g., /usr/lib/slrn/slrn.sl,
that will register various hooks so that when slrn needs to mime
encode/decode something, it will call the appropriate hook to perform
this task.

Perhaps later today or next weekend, I will check my changes into the
slrn source code repository (svn, not cvs) for others to look at and
try out.  If so, I will make an announcement here.

Feel free to make other suggestions about what you would like to see
in the next release.  Also please let me know of any problems that you
are experiencing with the currently available versions of slrn.  For
example, if slrn cannot properly cope with an article, let me know
what the problem is as well as its Message-ID.  Of course patches are
always welcome.

Thanks,
--John

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.