incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: mount_point character restrictions and repositories
Date Wed, 24 Apr 2013 20:39:15 GMT
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/merge123@allura.p.sf.net (mailto:merge123@allura.p.sf.net) 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/merge123@p.sf.net (mailto:merge123@p.sf.net) 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.)
>>> new@tickets.allura.p.sourceforge.net (mailto:new@tickets.allura.p.sourceforge.net).
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 : dave@brondsema.net (mailto:dave@brondsema.net)
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>> <><
>>
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Mime
View raw message