Re: mailing list archiver chewing patches

On 30/01/2010 17:54, Alvaro Herrera wrote:
> Matteo Beccati wrote:
>> Il 19/01/2010 09:44, Magnus Hagander ha scritto:
>>> As long as the templating is separated from the code, it doesn't
>>> matter if it's a dedicated templating engine or PHP. The point being,
>>> focus on the contents and interface, porting the actual
>>> HTML-generation is likely to be easy compared to that.
>>
>> I've been following the various suggestions. Please take a look at
>> the updated archives proof of concept:
>>
>> http://archives.beccati.org/
>
> I like this.
>
> Sorry for being unable to get in touch with you on IM. It's been a
> hectic time here with only very few pauses.

Thanks :)

And no worries, I'm pretty sure you must be quite busy lately!

> Some things:
>
> * the list of lists and groups of lists are stored in two JSON files.
> Should I send you a copy of them so that you can tweak your code to use
> them? They are generated automatically from the wwwmaster database.
>
> * We have a bunch of templates that you could perhaps have used, if you
> hadn't already written all of it ... :-(

The templates and especially the integration with the current layout
still need to be rewritten when porting the code to python/Django, so I
I'm not sure if it's wise to spend more time on it at this stage.

Not sure about the JSON approach either. Maybe it's something that needs
to be further discussed when/if planning the migration of the archives
to Archiveopteryx.

> * While I don't personally care, some are going to insist that the site
> works with Javascript disabled. I didn't try but from your description
> it doesn't seem like it would. Is this easily fixable?

Date sorting works nicely even without JS, while thread sorting doesn't
at all. I've just updated the PoC so that thread sorting is not
available when JS is not available, while it still is the default
otherwise. Hopefully that's enough to keep JS haters happy.

> * The old monthly interface /list/yyyy-mm/msg*php is not really
> necessary to keep, *except* that we need the existing URLs to redirect
> to the corresponding new message page. I think we should be able to
> create a database of URL redirects from the old site, using the
> Message-Id URL style. So each message accessed using the old URL style
> would require two redirects, but I don't think this is a problem. Do
> you agree?

Sure. I was just hoping there was an even easier way (rescritct to
month, order by uid limit 1 offset X). I guess it wouldn't be hard to
write a script that populates a backward compatibility table. No need
for double redirects, it'd be just a matter of adding a JOIN or two to
the query.

> * We're using Subversion to keep the current code. Is your code
> version-controlled? We'd need to import your code there, I'm afraid.

I do have a local svn repository. Given it's just a PoC that is going to
be rewritten I don't think it should live in the official repo, but if
you think id does, I'll be glad to switch.

>> Last but not least, it's backwards compatibile with the
>> /message-id/* URI. The other one (/list/yyyy-mm/msg*.php) is
>> implemented, but I just realized that it has problems dealing with
>> the old archive weirdness (2009-12 shows also some messages dated
>> aug 2009 nov 2009 or jan 2010 for -hackers).
>
> I'm surprised about the Aug 2009 ones, but the others are explained
> because the site divides the mboxes using one timezone and the time
> displayed is a different timezone. We don't really control the first
> one so there's nothing to do about it; but anyway it's not really
> important.

It's not a big deal, the BC-table approach will take care of those
out-of-range messages. However there are a few messages in the hackers
archive (and most likely others) that have wrong date headers (e.g.
1980, 2036): we need to think what to do with them.

Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/