[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