Re: [Lurker-users] Lurker 1.0 Survey

[Federico S. I. <ji...@fr...>]

On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> Ok, I am going to finally start work on lurker 1.0.
> 
> There will be sweeping changes in this lurker version, but I need to
> know some things about the current user-base first. I am conducting
> this survey verbally and non-anonymously so that I can get more than a
> simple x users for this, y for that. If your answers are open for
> public debate, reply to the list. Otherwise, reply directly to me.
> 
> After I collect this information, I will post a lurker 1.0
> requirements list and design for further final feedback. After this is
> finalized, I will proceed to implement lurker 0.5, 0.6, ... 0.12 until
> it's solid -> 1.0.

This roadmap sounds really good. Exciting news for the future. :)

> 1.  Does your platform have g++ 3.2?
> 1a. If you do not have g++ 3.2, do you have an ISO C++ conformant compiler?
> 1b. How much pain does setting it up cause you?

I use Debian GNU/Linux and it has G++ 3.2 (at least in Sid).

> 2.  Is 'jam' available for your platform?
>     <http://www.perforce.com/jam/jam.html>
> 2a. How much pain does setting it up cause you?

It seems Debian has a Jam package, as well. I am curious: how much
overhead is using Jam going to remove from your current build system? I
hope Jonas Meurer won't have problems working with Jam for the Debian
package of Lurker.

> 3. Rank the dependent libraries in order of *DEcreasing* pain:
>    libst, libc-client, libxslt1, libiconv
> 3a. Would you rather lurker.tgz include needed libraries?

I'm a spoiled brat with Debian. The current "just lurker, depending on
other libraries" is pretty ok with me, but I'd give my vote on this to
whatever Jonas Meurer has to say.

> 4. Rank these lurker features in *DEcreasing* importance:
>    capacity, threading, caching, search, mime-support, multi-lingual, xslt
>    ... indicate the point where you stop caring.

1. Search
2. Threading
3. Capacity
4. MIME support
5. Caching
[ Don't care ]
6. Multi-lingual
7. XSLT

> 5. Would you prefer lurker to run as a normal CGI or do you prefer it's
>    create-page-on-demand 404 error handler approach?

Whichever allows you to keep your codebase clean.

> 6. Small database size or fast database?

Fast database, as long as the database size is not profanely large vis a
vis the size of the messages stored.

> 7. Back-issue import w/o reimport or date-sorted search?

Having to rebuild the database for back-issues is a hassle, but for the
cleanliness of your codebase and date-sorted searches, and considering
the fact that database rebuilds are getting faster with every point
release, feel free to keep the current system of having to rebuild for
back-issues.

> 8.  Pretty or small html?
> 8a. How big is too big for the output html?
> 8b. Is lynx compatability (like now) important?

The current look is nice, clean, direct, and awesomely easy to navigate.
Prettyness isn't a big issue. Useability is. (Useability doesn't mean
Lynx, but I guess some people will appreciate that.)

> 9. How much RAM is too much for lurker to use?

The memory used indirectly by mmap right now is a bit on the high side,
but I have noticed that it's only noticeable during database rebuilds,
after which the kernel cleans things up so it's ok. For the stuff we
have at marc.free.net.ph, we have 512MB RAM shared with a lot of other
appso. I hope we won't need to upgrade to 1GB or more just to keep
lurker happy...

> 10.  Is cleaning up cached .html important or should I keep all valid html?
> 10a. If clean up: cronjob or daemon? (supposing no normal lurker daemon)

A spider could cause all mail HTMLized. While it's good to have valid
HTML on cache so that other spiders don't cause lurker to do too much
work, it may be a good option to have the cache purged by a cronjob
every now and then.

> 11. Have you ever used lurker's xslt to customize the UI?

Nope. UI's fine as it is.

> 12. Do you believe the majority of your users have an xslt-capable browser?

I don't even know. I haven't looked into XSLT enough... or at all. It
seems most people who use our archives have Mozilla or MSIE.

> 13. What url-scheme for message viewing do you prefer? (bookmarks/google):
> 	message/message-id.xml	<-- current
> 	message/YYYYMMDD_Subject_Author_Name_22.xml
> 	message/34534.xml
> 	other

Message ID is fine, and seems sound because it's constant across
database rebuilds. If 34534.xml will be constant even when we rebuild
and add back-issues then that'll be easier to link to. 

> 14. What should be improved most in lurker? (other than stability)

Stability. ;)

Seriously, next to that, more search options and faster database
rebuilds might be nice, but I'm really quite satisfied with how things
are sans the stability issues.

> 15. Do you know anyone who would like to help with lurker development?
>     In what capacity?
>     ... if the xslt is voted to stay in, I particularily need someone to
>     help with the xml---xslt-->html rendering; lurker needs a sharper look.

I will help with debugging, and maybe later on with the code but I don't
think you need help in that area since you're doing a very good job as
it is.

> 16. Other comments on lurker's future?

Just keep going. We're here to cheer you on. :)

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.