Bugzilla – Full Text Bug Listing
| Summary: | sites - easy way to restart a site that fails | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mamacdon |
| Version: | 0.4 | ||
| Target Milestone: | 6.0 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
a variant of the first idea. Use the subdomain to figure out the outer host's path. Construct a URL that directs to that host's site page, using a command URL binding to invoke start. Then the user would just click the link in the error message and hit "Enter" rather than having to select which site they wanted. (In reply to comment #0) > - when the site fails, could it possibly direct you to a page that would let > you start it? (i seem to remember there was some technical limitation, but is > there even a hack to get rid of subdomain on the path and just take the user to > the hosting site page?) Yes, this should be doable for 0.4. I can redirect to your sites page, where you could click to launch it again. That's 1 less manual step. > - a hover on the sites page could show the list of sites and include buttons > for starting and stopping (ideally the primary nav links extension could > generically handle a popup, but is there a hack we could do to enable such > popup...) Having a hover in the nav banner would be cool, but what does a hover on the sites page offer over the current sites page? (In reply to comment #1) > a variant of the first idea. > > Use the subdomain to figure out the outer host's path. > Construct a URL that directs to that host's site page, using a command URL > binding to invoke start. Then the user would just click the link in the error > message and hit "Enter" rather than having to select which site they wanted. I like this idea for post-0.4. It would require a stronger link between subdomain and site configuration -- the hostname you provide for a site would have to be unique on the server so we can do this reverse lookup. (But that may be a good idea regardless, since it mitigates the security problem of allowing any user to claim a subdomain that I thought was mine -- eg. you can launch a site at mark.orion.eclipse.org and trick me.) Separate from that, running sites could be persisted. There's no technical barrier, they just seemed like a transient thing originally, like a child process of the server. I realize that doesn't make much sense for our usage patterns at orion.eclipse.org. (In reply to comment #2) > > - a hover on the sites page could show the list of sites and include buttons > > for starting and stopping (ideally the primary nav links extension could > > generically handle a popup, but is there a hack we could do to enable such > > popup...) > > Having a hover in the nav banner would be cool, but what does a hover on the > sites page offer over the current sites page? speed is the theory, though with our various dependencies I'm not sure it's true. The idea is that you hover, click on a site to start it, and you didn't have to wait for a whole new orion page with all the bells and whistles to load. This is actually more of a general idea, where orion pages in general could offer up hovers with the "80%" functional case offered and then link the full page. This is clearly a post 0.4 idea. (In reply to comment #3) > The idea is that you hover, click on a site to start it, and you didn't > have to wait for a whole new orion page with all the bells and whistles to > load. Oh I agree. The question in #c2 was a misunderstanding (I thought you were talking about 2 different kinds of hovers). > speed is the theory, though with our various dependencies I'm not sure it's > true. Yeah, we'd want to defer loading a hover until it was actually used, or else every page would be a huge download. I guess a hover would also need to be able to instantiate concrete implementations of the services it needs -- since it can't expect the outer page to provide every possible service. Vetoed for RC2. I've got a fix in progress. Will implement early in 0.5 to take some of the pain out of upgrading builds every day. Fixing this was complicated by the fact that "inner" sites currently aren't aware of the hostname of the "outer" server, so I can't construct a redirect in response to an inner-site request that points you to the outer server. This can be done but I won't have time in M2. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |