Re: Using MHonArc as more than an archive?

[Earl Hood <earl@earlhood.com>]

On June 23, 2003 at 15:11, Harshal Chhaya wrote:

> That's similar to what I do on one of my lists. The archives
> are public so anyone (not just list members) can follow the discussions. 
> I use the <DayBegin> and <DayEnd> resources to highlight the daily
> messages and build a calendar-view of the archive from the messages.
> 
> You can see how this looks at 
> http://www.mumbai-central.com/grapevine/calendar.html

Nice.

> (the calendars are built by a perl script that greps the
> archived HTML files for dates) 

There appears to some kinks.  For example, checkout Feb 17, 1999:
<http://www.mumbai-central.com/grapevine/mail21.html#19990217>

> > * Some way to (optionally) view the contents of an entire thread at a time.
> 
> Earl had mentioned that he had created a custom extension to mhonarc
> that displayed all the messages of a thread on a page. He also mentioned
> that all the resources and other information is available so anyone
> interested in this could build it themselves.

The script does utilize internal structures of MHonArc.  It makes
it more efficient.

> I haven't studied the 'blog.mrc' resource file but it might do
> part of what you want. The file is at 
> http://www.mhonarc.org/MHonArc/doc/rcfileexs/blog.mrc.html
> and other examples are at 
> http://www.mhonarc.org/MHonArc/doc/app-rcfileexs.html

Unfortunately, blog.mrc does not make a distinction about separate
threads.  An initial version of the script I did utilized a SSI
technique, but the client had requirements that made that not doable.
Despite not wanting SSI for search indexing reasons and extra server
load, they wanted to preserve the regular format of individual message
pages.  The blog.mrc model does not do that since each message page
is designed to be included via the resource customized index.

There were some other client requirements that made the script
non-trivial and there is a small dependency on some resource settings
for it do its job properly.  It definitely helped to know MHonArc
internals since some tasks would be very cumbersome to do if solely
relying on post-processing of message pages.

I'm considering generalizing it (remove client-specific convenience
features) and including it in the extras directory, but it has not
been high priority, even though it is kind of cool :-)  I think
I would want to restructure it so something like mharc, or other
programs that use embedded MHonArc, can leverage what it does.

--ewh

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@mhonarc.org with the
message text UNSUBSCRIBE MHONARC-USERS