Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340204 - [sites] Start/stop API is not RESTful
Summary: [sites] Start/stop API is not RESTful
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Client (show other bugs)
Version: 0.2   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 0.2   Edit
Assignee: Mark Macdonald CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-16 13:58 EDT by Mark Macdonald CLA
Modified: 2011-09-01 11:41 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Macdonald CLA 2011-03-16 13:58:36 EDT 
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.
Comment 1 Mark Macdonald CLA 2011-03-23 15:06:04 EDT 
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).
Comment 2 Mark Macdonald CLA 2011-03-23 15:06:25 EDT 
(In reply to comment #1)
Oops, wrong bug. Ignore Comment #1.