[Mailman-Developers] Re: Requirements for a new archiver

[David Champion]

* On 2003.10.28, in <20485453-0988-11D8-A02B-0003934516A8 at plaidworks.com>,
*	"Chuq Von Rospach" <chuqui at plaidworks.com> wrote:
> 
> because once you leave the niche of dealing with your fellow geeks, 
> that's what users are going to want. browser access. NNTP is simply a 

It's the "non-geeks" I'm trying to help: I support 25,000 of them, and
I really don't worry much about the "geeks". They know how to do for
themselves.


> non-issue any more, and iMap is fine, but they know how to go to a URL, 
> don't assume they can reconfigure their mailer.

Where I work -- and I know that it's not like this everywhere, but
I have to assume we're not the only place like this -- we configure
users' mailers for them initially. (So we can configure in access to our
list server(s).) We have a telephone support line that regularly works
people through mailer issues. Here, reconfiguring a mailer is not a
hard problem, compared to getting usable HTML archives in a supportable
server configuration.


> Not saying don't do this, but if you write geek tools for geeks, you'll 
> lose the rest of your audience, the non-technical users.

Agreed, but I don't think I'm proposing "geek tools". I'm trying to
establish a shared pathway for getting into a message archive that lets
geeks use their tools, and non-geeks use theirs, equally.


> >Nobody needs web access: what they need is
> >access via a web browser. With browsers that understand NNTP and IMAP
> >prevalent, and with a wide selection of web-mail and web-news gateways
> >for the cases where that doesn't work, this is sufficient.
> 
> is it? it seems to me to (frankly) be a real hack with bad navigation, 
> at least the stuff I've seen. I'd be happy to be proven wrong.

What seems to have bad navigation? I'm not sure what component you mean.
I would say that webmail programs generally are awful, but I know that
40% of my users love using them. I think it's also relevant that every
web-based list archive I've ever used is atrocious for navigation; their
only selling points seem to be ease of referral and indexing. (And yes,
I agree that these are important elements.)

But granted, this is an overzealous assessment. I should say: IMAP and
NNTP access are sufficient for certain environments of which I believe
mine is an example.


> And for intermittent or one-time access to an archive? won't bother. 
> And how does it get into google so they know to look at it in the first 
> place?

Again, I'm not talking (for the most part) about public-access lists.
I'm talking about private communities consisting mostly of people within
a common real-world context. Perhaps I should have made that more clear.
This happens a lot: I seriously doubt that most mailing lists, even most
Mailman mailing lists, are public.


> I'm not really thrilled with this avenue. sorry.

Don't be sorry. I want to google certain lists as much as the next
person, and I know that this model doesn't work as well as HTML archives
in that respect (though I will note as a sidebar that Google happily
indexes NNTP servers). I'm not trying to kill the web archive go
before its time, and nothing I've proposed obviates having one. All
I've described is a parallel mode of access that I believe is more
appropriate and more useful in some settings.

We're already plugging external archivers into Mailman now, and nothing
in this suggestion prevents us from continuing to do that. The only
potential change, I would say, is that in one design, archivers would
pull from NNTP, IMAP, or a message store, rather than actively being
fed articles. I don't particularly advocate that, lacking a better
understanding of the internals of the list server. I take no issue
with leaving in a means of delivering messages to archivers, I just
would like to see it become one of several access messsage channels,
preferably all with some shared interface to the core processor.

-- 
 -D.    dgc at uchicago.edu
 University of Chicago > NSIT > VDN > ENSS > ENSA > You are here
 .  .  .  .  .  .  .
 always line up dots