new web app urls discussion

Kevin Fenzi kevin at scrye.com
Mon Feb 6 19:53:09 UTC 2012


ok. I want to revive this thread and come to some conclusion we can act
on. ;) 

So, in the specific case of the new packages/tagger: 

http://packages.fedoraproject.org
and
http://apps.fedoraproject.org/packages/
and
http://pkgs.fedoraproject.org (front page only, probibly redirect to
above page). should go to the packages app.
Which is the 'real' url that the others direct to?
Or do they all work ? We would have to monitor and support all of them? 

http://tagger.fedoraproject.org/ 
and
https://apps.fedoraproject.org/tagger/
and
https://tagger.fedoraproject.org
go to the tagger application. 

This means that we can't share signin on tagger, unless we move our
other applications that have login cookies under apps.fedoraproject.org
and make that the preferred url right?

Since we have that under admin. Should we instead put tagger: 

https://admin.fedoraproject.org/tagger/ 

At least for now until we move other applications that use admin?

Additionally: 

http://apps.fedoraproject.org/
  (landing page with links to all the other stuff). 
  (Note: this might be a nice place to show icons/links to upstream
  projects we use and support too).

http://apps.fedoraproject.org/<name>
and
http://<name>.fedoraproject.org/

I know mmcgrath had a pretty good policy of "no CNAMES". Ie, everything
should be one actual name to avoid confusion about what url people are
hitting and what we monitor, etc. I see the above makes things easier
in some ways, but also more confusing. I think we should be very clear
what the "real" url is and have the other convenience ones just redirect
to that. 

Thoughts? 

How can we make this more clear and not have a forest of urls? 
:) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120206/119670d7/attachment.sig>


More information about the infrastructure mailing list