Re: mailing list archiver chewing patches

On 31/01/2010 13:45, Magnus Hagander wrote:
> On Sat, Jan 30, 2010 at 22:43, Matteo Beccati<php(at)beccati(dot)com> wrote:
>> On 30/01/2010 17:54, Alvaro Herrera wrote:
>>> * 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.
>
> I haven't looked at how it actually works, but the general requirement
> is that it has to *work* without JS. It doesn't have to work *as
> well*. That means serving up a page with zero contents, or a page that
> you can't navigate, is not acceptable. Requiring more clicks to get
> around the navigation and things like that, are ok.

As it currently stands, date sorting is the default and there are no
links to the thread view, which would otherwise look empty. We can
surely build a non-JS thread view as well, I'm just not sure if it's
worth the effort.

>>> * 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.
>
> Once we go into production on this, we'll need to do some serious
> thinking about the caching issues. And in any such scenario we should
> very much avoid serving up the same content under different URLs,
> since it'll blow away cache space for no reason - it's much better to
> throw a redirct.

Yes, that was my point. A single redirect to the only URL for the message.

>>> * 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.
>
> Note that the plan is to switch pgweb to git as well. So if you just
> want to push the stuff up during development so people can look at it,
> register for a repository at git.postgresql.org - or just set one up
> at github which is even easier.

The only reason why I used svn is that git support in netbeans is rather
poor, or at least that was my impression. I think it won't be a problem
to move to git, I probably just need some directions ;)

Cheers
--
Matteo Beccati

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