Remote library interface

Description of Feature:

Provide integration between OpenRocket desktop application and one or more remote servers which provide access to contributed OpenRocket or RockSim model files. OpenRocket will utilize HTTP protocol methods to retrieve a list of available model files, retrieve a user selected model file, and (optionally) allow the user to upload model files to the remote server.

General discussion:

The remote library will be identified by a single base url. OpenRocket might include a preconfigured list of available remote libraries but will allow the user to enter an arbitrary URL in a text box to provide access to remote libraries which come online after a given release of OpenRocket. Example base url: http://127.0.0.1/OpenRocketLibrary

Retrieve listing of model files: OpenRocket will use an HTTP GET method to request a list of all available models from the user specified remote library URL. The listing will provide some metadata about each of the available model files including:

• Author - a string which represents the author of the model file. Will most likely be the username of the user on the remote server who uploaded the file.
• Model Name - a string which describes the model file. For example: "A simple model rocket", or "Estes Magician 3x upscale".
• Category - a string which the remote server might use to categorize model files. Might represent manufacturer of the kit, "scratch", or other string.
• Download URL - a string which is used by OR when retrieving the model file from the remote server (further discussion is needed)
• Web URL - a string which is optionally provided by the remote server. When selected by the user would open a browser with the specified url. Example use might be link to RocketReviews product index page for the model, for example: http://www.rocketreviews.com/alien-space-probe---estes-2038-1990-1992.html

OpenRocket will issue a GET request for <baseURL>/listing. It is desirable to not use get parameters for the listing url in order to support (download only) libraries implemented as a sequence of static pages served by simple HTTP servers.

The response provided by the server will contain the listing in the body contents as an xml file. Proposed format:

<entries>
  <entry>
   <author></author>
   <name></name>
   <category></category>
   <downloadurl></downloadurl>
   <weburl></weburl>
  </entry>
</entries>

Download model file: When the user selects a model from the displayed list and chooses to load it. OpenRocket will download the model file, parse it into an OpenRocketDocument and open a new BasicFrame for the model. OpenRocket will use a simple HTTP Get method on a url and the server will provide the model file in the content body of the response.

What mimetypes should be used to recieve binary content (such as gzipped ork files, or zip ork containers)?

What URL should be used? There are two options:

• relative downloadurls - OpenRocket would issue a GET request for <baseURL><downloadURL>. This arrangement would provide some level of security because the remote library model files would be downloaded from the specified host. The remote host could provide query parameters if necessary for its implementation.
• absolute downloadurls - OpenRocket would issue a GET request for <downloadURL> which must be a complete url. This option might provide easier implementation for remote library providers.

Upload model file: OpenRocket may provide a mechanism to contribute a model file to a remote library. The remote library would have to implement its own user authentication system for security. This option would probably be presented to the OpenRocket desktop user as a variation on "Save as" with its own menu option.

It is suggested that the remote library use digest authentication. OpenRocket would provide a dialog box asking the user for his username and password on the remote library server. In addition, certain metadata about the model file may be requested (in particular, name and category).

OpenRocket would use a POST method to <baseURL>/upload url. The body would be multipart. The metadata might be provided as X- HTTP headers, or may be provided as query parameters to the post. The model itself will be included in a file attachment.