Re: mailing list archiver chewing patches

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mailing list archiver chewing patches
Date: 2010-01-31 12:45:09
Message-ID: 9837222c1001310445r780f85ads20d0c42a8745d986@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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.

>> * 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.

>> * 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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2010-01-31 12:48:24 Re: Using the new libpq connection functions in PostgreSQL binaries
Previous Message Ivan Sergio Borgonovo 2010-01-31 12:43:36 Re: development setup and libdir

Browse pgsql-www by date

  From Date Subject
Next Message Matteo Beccati 2010-01-31 14:09:17 Re: mailing list archiver chewing patches
Previous Message Matteo Beccati 2010-01-31 12:38:11 Re: mailing list archiver chewing patches