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 "web...@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.
pgp7U9jy8q3j6.pgp
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
