Also I have a question related to fan.sys.Uri (and may be a reason for another discussion): why pod uri is not environment-independent? For example, for desktop application I should have `fan:/sys/pod/icons/x16/folder.png` while for browser-application it should be `/sys/pod/icons/x16/folder.png`. Is it really make sense?
The main reason Pod.uri can't be independent, is in the browser for instance, we only have Http to communicate. So in order to access pods we need the Pod namespace to be accessible via a browser-friendly Uri.
We haven't really solved this well yet tho I don't think. I've sorta skirted around this for my SkyFoundry work. But what we need is a configurable way to specify how the Pod namespace gets mounted into the current Uri space. And then anyone who depends on a pod resource, can guarentee they get the right Uri. Not sure how that works yet, I've given it alot of thought.
brianTue 20 Oct 2009
The main reason Pod.uri can't be independent, is in the browser for instance, we only have Http to communicate. So in order to access pods we need the Pod namespace to be accessible via a browser-friendly Uri.
My thoughts: the URIs used by application code should always be exactly the same regardless of runtime platform. While we might not support certain APIs in the JavaScript environment, we should never introduce semantic differences. So I think application code should use fan: URIs consistently. How that maps to HTTP calls under the covers is where JavaScript has platform specific stuff. There really isn't reason JavaScript sys can't trap on fan: URIs and take the appropriate action (other than some missing infrastructure to configure a mapping).
Yuri Strot Tue 20 Oct 2009
Hello,
Looks like a little misprint in Uri.js, please look at the following patch:
Also I have a question related to fan.sys.Uri (and may be a reason for another discussion): why pod uri is not environment-independent? For example, for desktop application I should have
`fan:/sys/pod/icons/x16/folder.png`
while for browser-application it should be`/sys/pod/icons/x16/folder.png`
. Is it really make sense?Best regards,
Yuri Strot
andy Tue 20 Oct 2009
Thanks Yuri - I pushed your patch.
The main reason Pod.uri can't be independent, is in the browser for instance, we only have Http to communicate. So in order to access pods we need the Pod namespace to be accessible via a browser-friendly Uri.
We haven't really solved this well yet tho I don't think. I've sorta skirted around this for my SkyFoundry work. But what we need is a configurable way to specify how the Pod namespace gets mounted into the current Uri space. And then anyone who depends on a pod resource, can guarentee they get the right Uri. Not sure how that works yet, I've given it alot of thought.
brian Tue 20 Oct 2009
My thoughts: the URIs used by application code should always be exactly the same regardless of runtime platform. While we might not support certain APIs in the JavaScript environment, we should never introduce semantic differences. So I think application code should use fan: URIs consistently. How that maps to HTTP calls under the covers is where JavaScript has platform specific stuff. There really isn't reason JavaScript sys can't trap on fan: URIs and take the appropriate action (other than some missing infrastructure to configure a mapping).