[Mailman-Developers] URGENT: Google Summer of Code status report and code due
Alexander Sulfrian
alexander at sulfrian.net
Thu Jul 12 12:39:14 CEST 2012
At Thu, 12 Jul 2012 17:44:37 +0900,
Stephen J. Turnbull wrote:
> Alexander Sulfrian writes:
>
> > If the list_name would be also reversed, it could lead to some
> > surprising subtree clashing. For example web2.0 would be in the same
> > subtree like something1.0 (people sometimes use strange list
> > names...).
>
> I agree that list_name should *not* be reversed; it is an atom.
>
> This "atomicity" is a problem. We have three different namespaces and
> syntaxes to deal with here: RFC 5322 email addresses, RFC 2919
> List-Ids, and RFC 5536. In RFC 5322, there's a special class, the
> "dotted-atom", which may be used in the mailbox component of an
> address (and thus denotes an atomic resource). But not in RFC 5536,
> where dots aren't allowed in newsgroup name components. I think this
> is a problem for post-GSoC, though.
>
> > Even with the current implementation the group names are
> > ugly.
>
> I would expect that MUA presentations will deal with this. For
> example, exploiting the hierarchy, the dots could appear as
> breadcrumbs:
>
> mailman > org > python > mailman-developers
>
> MAILMAN-DEVELOPERS
>
> [summary lines]
>
> [current message header info such as author, subject, date]
>
> [current message body]
Yeah, it is currently working this way. The ugly names, I refered to,
occur for example with "web2.0 at example.com":
com > example > web2 > 0
Thunderbird is even more ugly. It shorten the name in the overview to
display only the first letter of each subtree:
c.e.w.0
But as you said, I will leave it for now in this state and keep in
mind, that we should find a better solution in future.
> > Maybe we should eliminate the dots from the list names by default
> > and only allow separate groups with the alias mechanism?
>
> Quite possibly, but don't worry about it for the purposes of GSoC I
> think. The worst that would happen is that a few, relatively unusual
> lists would be inaccessible. But I think dealing with this requires
> some thought, so let's not get committed to a hasty design. Document
> that dotted names may show strange behavior (including being
> inaccessible), and move on for now.
Despite of having a unusual name all lists should be accessible. The
current implementation should not lead to inaccessible groups. So I
think it is acceptable for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120712/203dbc00/attachment.pgp>
More information about the Mailman-Developers
mailing list