>> #1. SubEtha Mail isn't the type of application to get ported to other
>> languages.
>
> You mean you can only write mailing list managers in JSP?
> The issue is porting the data, not the application. I'm sure
> you're not in favor of product tie-in using closed data formats?
You can export the data into whatever format you want. We currently
support mbox and sql. Since there is no standard for how MLM's
generate their archive urls, even importing the data into another
product won't necessarily promise urls that will work with another
product.
> I didn't say that.
Ah, but you did give mailman as an example of a system that does
things the way you want it to. I'm suggesting that mailman also does
things incorrectly.
> Ending in .html is also discouraged, because in the
> future it might make sense to use a different format. However, .jsp
> is worse than .html, since .html is at least the *data* that is sent
> to the browser, while .jsp is just the language the server is
> implemented in, and has nothing to do with the actual data. .html
> is formatted "concrete" data, rather than an abstract "RESTful"
> location, which is why .html should be avoided, but at least it is
> data.
> And there is one argument for using .html extensions: a static
> copy of an archive or can be saved to a disk and read with a file:
> URL.
I've built sites that end with .html yet are really heavily processed
PHP sites. Again, it's just a suffix mapping. In the past, it's been
thought that search engines weight .html pages higher than other
suffixes so there is some advantage to doing what I did.
> This article is useful, and includes various links:
> http://www.port80software.com/support/articles/nextgenerationurls
There is some good stuff in that article, and a few glaring
inaccuracies, but overall it's not much new.
> A URL for a message should just that message, along with various
> navigation links.
>
> A URL for a thread shows links to all the messages in the thread.
> It may optionally inline or summarize the message content in a
> blob/forum style. At least conceptually: for a long thread, one
> may need multiple pages, but the primary nagivation buttons are
> for moving within that thread.
I guess what I'm saying is that I'm not quite sure how that is any
different from say... this link...
http://www.subethamail.org/se/archive_msg.jsp?msgId=20280
It inlines the message and shows links to all the other messages in
the thread.
> A two-pane view is nice for reading a thread, since you can see
> the context while your reading and message - and skip messages
> from known flamers.
Right... which is why I use and like Mail.app, however the interface
on gmane needs quite a bit of work to actually be enjoyable.
> That's fine if you want to read *every* message in a thread. But what
> if you only want to read the message from people who usually write
> something interesting?
Then your system should filter it for you. ala /. moderation.
> In your mail reader, don't you prefer a two-pane view to a one-pane
> view? I certainly do. Using squirrelmail (for example) is tedious
> because it only has a single pane view.
Yes, but my opinion is that the example of gmane as being a good UI
is bad.
>>> Using AJAX (when available) rather than frames would be probably be
>>> an improvement.
>>
>> What about a gmail style interface?
>
> Nothing wrong with that - the extra navigation buttons at the
> bottom are
> an improvement over mailman. However, a two-pane view is even nicer.
Regardless, I think we are in agreement that providing better urls is
a good goal and is relatively easy to implement. Thanks for your
input on the matter. I just filed an enhancement issue to track it....
http://subetha.tigris.org/issues/show_bug.cgi?id=150
cheers!
jon
