Bugzilla – Full Text Bug Listing
| Summary: | [sites] Start/stop API is not RESTful | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Using a (partial) fix for this, I've managed to get Orion-in-Orion hosting to work: the orion.client.core and orion.client.editor bundles are served from my Orion workspace, and other requests pass through to the running Orion server. So when I go to 127.0.0.2 I log in to my "real" Orion server, but the client-side JS UI code I get is the code that I'm developing. The upshot is that I can self-host, but fall back to the "real" Orion when I need to recover from a wrecked JS environment. However, there are some strange interactions when proxying the authentication process that I don't totally understand yet, and I've had to tweak the auth code to avoid them. It's probably an issue on my side. One other problem is due to a limitation with the current site hosting support, which is that each "mount at" path can only point to 1 workspace path (or remote URL). It's a problem because a path like "/js" on an Orion server needs content from several different workspace locations (eg. the git bundle and the core bundle). (In reply to comment #1) Oops, wrong bug. Ignore Comment #1. http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/?id=c68ee8eeb557d2cda00d80b9eab297b3111d334a http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=e62f6837217ef1305297f7f1d1112678655b65cf Starting and stopping a site is now done via a PUT on the site configuration resource. |
Orion 0.2 M6 From the orion-dev mailing list: > This is essentially an RPC API rather than a REST-oriented API (execute some arbitrary command on a resource via POST). It seems like this could instead be accomplished via a simple PUT on the site configuration resource, since the "status" (started/stopped) is just a property of that resource. I.e., you are not creating any resource here, but instead just modifying the "status" property of a site configuration resource. This start/stop operation is idempotent which makes it suitable for PUT - for example trying to stop a site that is already stopped is a harmless no-op.