Enforcing absolute paths https://developer.mozilla.org/en/Apps/Manifest#path-handling are painful enforcement for development purposes. It means that I can't just simple share code with other peers or they need to have similar dev server setup on their machine. Dependency on server during app development is painful. Also those urls in development very likely will be `http://localhost/...` while at deployment they will have to have a different URLs. Allowing relative paths would make development and deployment much easier.

The doc is badly phrased. It's ok to let out the http://SERVER:PORT/ part, but your paths must start by a /

This is not the same issue as bug 745928

(In reply to Fabrice Desré [:fabrice] from comment #3) > This is not the same issue as bug 745928 Ah right

I am unclear of the problem as described here. The absolute paths don't and shouldn't include the scheme and domain. Therefore it is not easy to move an application into a subdirectory, but it can move between domains or ports with no changes to the manifest. However, the use case Irakli uses is not about subdirectories. Perhaps the situation is okay already for Irakli's needs and this is a confusion about documentation?

Let me elaborate it little bit more. My immediate thought was to create an app that does not has any backend, but uses public services instead. To do that kind of app I'm likely going to set up a githup repo for a webapp. That way I'll be able to use http://pages.github.com/ to deploy that app. To do a development locally I will have to: 1. Use some dev server 2. Have a route on a dev server matching gh-pages. Now once published, hopefully people will fork, adjust to their needs or even better send back improvements. To do that they will need to: 1. Clone repo. 2. Run dev server. 2. Set up a route on dev server to match gh-pages. That being said I can see how existing scheme would work perfectly fine for big websites. But I really wish webapps made it easy to make a hackable apps that won't have to be tidily coupled with a location. Ability to use relative URIs would have made all of this a lot easier.

I still don't understand your concerns, Irakli. Can you post the manifests and origins for the different instances? There should be no need for changes in the manifests.

Let me give you very specific example: I'm playing with an example app that on my machine is located at: /Users/gozala/Projects/sky-edit/index.html In order to develop it I use pre-installed apache server on OSX. So url to it is: http://localhost/~gozala/projects/sky-edit/ Now `launch_path` of this app in manifest should be: /~gozala/projects/sky-edit/ This `launch_path` obviously won't match the one in the deployment target, for example gh-pages, since url to the app there will be: http://gozala.github.com/sky-edit/ and there for `launch_path` there should be `/sky-edit/` Now this I obviously can solve this by trying to re-arrange files on my fs or by running different development server to have a `launch_path` that would match one on gh-pages. But then anyone trying to contribute the patch will have to go through this pain on their machines, as they will need to arrange same `launch_path` in order to test it. Simply allowing relative paths would have solved all of these issues. And would ease the contributions to the project.

I think using github pages as you suggest will already work poorly with mozApps – we only allow one application on an origin; in this case the origin would be "http://gozala.github.com" – so you could not have one application at /sky-edit/ and another at /some-other-app/, each of them have to be on their own domain. So you'd have to set up a custom domain of some sort (which can still be done using github pages, but requires your own domain: https://github.com/blog/315-cname-support-for-github-pages) I believe because of the single-application-per-origin restriction that relative paths aren't very useful. Note someone could still fork a project and publish it elsewhere, but (to work easily) it would have to be published at the same top-level path as the original application.

What Ian says is true, for now, but we'll move to a model where apps are bound to their manifest uri, and not to the origin. When critical platform pieces for that will be ready (e.g. permission management using this new model) we'll switch to resolve uris as relative to the manifest uri.

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.