> 1. simple for users and remember
> 2. not overlapping with any of the older apps or existing urls
> 3. futureproofing for new apps or different interfaces
> 4. expanding the number of apps we have w/o having them grouped under a
> single project (like community was).
> - no interest in pinning anything/everything behind admin.fp.o
Why can we not forward everything through a filter? For instance:
where render is a rewrite to a method that determines which host a
particular project resides on. This approach would scale and seems to
fit the requirements. In terms of making it "easy for users" we would
still have to come to a consensus on whether to use
. Either way these
could then be mapped "internally" through our proxy/webserver of
choice to the proper rendering method + option(s).
I imagine this solution might cause a problem with SSO and cookies so
it might be a non-starter unless we are able to migrate to more of a
unified RBAC model where someone authenticates to our "root" domain
but then access to other applications is granted per site. Such an
approach might also help cleanup the authentication, authorization and
accounting (AAA) issues new applications sometimes experience by
enabling us to write a "clean authentication module" developers can
import to make their application "Fedora Project AAA Compliant." A big
task indeed but it might help with NIHS for new applications.
Maybe I didn't think this through? thoughts, suggestions, explicatives? :-)