Yes, and maybe a few more characters too, based on what we see in common usage (e.g at http://cygwin-ports.git.sourceforge.net/git/gitweb-index.cgi and http://fedora-cygwin.git.sourceforge.net/git/gitweb-index.cgi). But keep it to a minimum, so that we have the flexibility to do new email routing later and still have several reserved chars at our disposal for separators.
Another change could be to allow a non-alpha as a first character. That was mentioned on https://sourceforge.net/p/allura/tickets/5501/ but is more relevant to implement here on https://sourceforge.net/p/allura/tickets/5332/ That said, I don't know what the use-case is. If it's not for code repos then it's a different story altogether. -Dave On 4/24/13 4:29 PM, Tim Van Steenburgh wrote: > Dave, > > So are you proposing that we change the definition of valid mount point to > include _ and . but only for repos? > > Tim > > > On Friday, April 19, 2013 at 10:23 AM, Dave Brondsema wrote: > >> . and _ are the most common characters but there are others like = or , that >> would be valid in a folder name for a repo, but not as a subdomain. >> >> Right now we don't have any functionality to send an email to a repo, so >> nothing >> would break yet. But it's likely that we'd want make replying to a merge >> request email work some day. I think we probably could determine a different >> routing mechanism at that point. E.g. something like >> my_repo/[email protected] (mailto:[email protected]) would be >> plausible (moving the mount point >> before the @ and using a separator that would never be a valid mount point >> char). Or even allura/my_repo/[email protected] (mailto:[email protected]) >> so there are no dynamic >> subdomains, which would make mail server configuration easier for anyone >> deploying Allura. >> >> Current email routing code is at >> https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/tasks/mail_tasks.py >> and >> https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/lib/mail_util.py#l77 >> for the interested. >> >> Overall I'd prefer keeping mount points and their email addresses simple (as >> opposed to complex and powerful) and also human-friendly. >> >> -Dave >> >> On 4/18/13 6:58 PM, Cory Johns wrote: >>> Allura currently restricts the use of . and _ (period and underscore) in >>> the mount_point when installing a tool / app. This was originally done to >>> enable to routing emails to to the app via the form (e.g.) >>> [email protected] >>> (mailto:[email protected]). However, this has become a >>> sticking >>> point for some users, specifically with regards to repository names (and in >>> particular with repositories migrated from other systems, such as >>> SourceForge's classic system which already allowed those characters). >>> Dave, Tim and I started discussing possible options for opening up these >>> characters, and we wanted to open up the discussion here. >>> >>> Initially, we were thinking that we could just have a flag that an app >>> could set that removed the restriction for these characters for the >>> mount_point of that app when installed on a project, with the understanding >>> that this would break email routing for that app. Tim also had the idea of >>> adding an additional "sanitized" version of the mount_point that could >>> still be used for routing in place of the normal mount_point. However, >>> there would be the potential for conflicts, albeit manageable, if the >>> sanitized version of one tool's mount_point matched the non-sanitized >>> version of another tool's mount_point. I floated the idea of going all the >>> way and using a guaranteed unique identifier, such as the app_config's _id, >>> but then the email address' domain would not be human-friendly. >>> >>> Is it worth coming up with a more complicated system to try to both >>> preserve email routing and allow the characters in the mount_point, or >>> should we just go with a flag and let the tools break their routing? Are >>> there any other ideas that strike a better balance? >>> >> >> >> >> >> -- >> Dave Brondsema : [email protected] (mailto:[email protected]) >> http://www.brondsema.net : personal >> http://www.splike.com : programming >> <>< >> >> > > > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
