Lars, I responded to your message from a year ago over there. I agree these are related issues. I think I favor the context as push-down-list -- I believe that handles a lot of the requirements I have seen.
Tom, I think your issue of 404s and imposing a web site structure is related to this issue that I also am having:
If you have an application that is made of one or more packages mounted at two or more (many!) different locations, how does the application determine the other locations?
Going back to the /blogs example, if jade comes and visits
/blogs, then /blogs/jade, then jade should see an admin link to /jade/blog/admin and similarly, when dave visits /blogs/dave he should see a link to /dave/blog/admin. Unless when these packages were mounted, the site admin mounted jades at /jade/blog and dave's at /tdx/daveb/blog
When mounting the same package at different locations, when a package can be mounted at arbitrary positions, how does any package determine the url of the correct instance of another package?
As of (quite a while ago) I hadn't seen a good way to do this, there was still a lot of hardcoding going on, or assumptions being made. What's the scoop now?
If there isn't a solution for this yet, I would like to see some sort of publish-cabilities, published-service registry created. Each package instance would have the ability to create a registry entry saying, I provide this service (blog), identified with these parameters (user = jade), and my canonical url is this (jade/blog). Does anything like that exist?
We could optionally enhance that with (I provide these services at these urls, examples: blog is at jade/blog, admin is at jade/blog/admin, trackback is at jade/blog/trackback)
I think that would help out some of the 404 problems. It would make it easier to keep 404s from occurring (does this service exist? where is it? does it provide this service? where?) And it would let the 404 handler provide a catalog of other or alternative services.
