[auscope-geosciml] RE : RE : URI resolution and javascript sandbox

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Aug 10 05:24:22 EDT 2010


Sorry, I've been confusing the issue.
I understand, the proxy does not need any specific configuration, it just resends whatever URL it receives.
 
My point was that since javascript applications (and we are likely to deploy a web application) needs that proxy component, I was reflecting on the irony that URL did not save us from a mandatory components to process them as their "explicitness" is not allow to be used anyway in a JS context and we might as well use this proxy as a resolver and keep URNs.  I remember the whole discussion about the location of a hypothetical resolver and it appears that the solution was likely "at the same place as the originator of the data".
 
I understand Simon's argument that URL can be made persistent, but I'm quite certain that in practice, URL will change quite often because the location of the vocabulary will change,server will go down, administration will change, etc..  breaking their uniqueness.
 
> Regarding the pros "minimise load", I think that the client (javascript or anything else) should have a way to load all the vocabulary and not just catching each new uri.
 
 yes, but we also have to deal with fragments (reference to other features) which can't be preloaded.
 
Eric
 

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Tellez-Arenas Agnes
Date: mar. 2010-08-10 03:09
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml]RE : URI resolution and javascript sandbox



I am sorry I still don't understand.

The javascript client proxy is not a resolver that needs to be configured. The client finds a uri to dereference. This uri is an http url. The client uses a proxy that just requests this url and returns back the response. This proxy can be used by any other part of the client, for any other http-rest web service. The proxy is a part of the client. I think that any javascript-based (ajax) client that needs to access to other applications (other domains) includes such a proxy (or uses other JSON technics). This proxy is not specific to our problem.

So we have: [CLIENT javascript finds a URL /URI => CLIENT non javascript-proxy requests the URL ] => uri resolver => get the content somewhere else

Regarding the pros "minimise load", I think that the client (javascript or anything else) should have a way to load all the vocabulary and not just catching each new uri.

Agnès

-----Message d'origine-----
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Rob.Atkinson at csiro.au
Envoyé : mardi 10 août 2010 01:23
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] RE : URI resolution and javascript sandbox

So, to do this you need two components:

1) a client that follows URIs by sending them to the proxy resolver to get the content
2) a proxy resolver that gets the content

This has some pros and cons:

Pros: the client and proxy can both cache to minimise load on the authoritative sources
Cons: you need to write and/or configure the client

Client configuration to find the right resolver could be accomplished by several means: establish a canonical location for the resolver, or pass the resolver address to the client in the first response, containing the foreign URIs - requireing a canonical mechanism for annotating the response with this - perhaps in the HTTP headers.

There is a problem with authorisation and access control - the proxy needs all your rights to access the resources. My gut feel is that this only works where the proxy is a service provided by the same node that provides authentication - i.e. portals. That may be OK - as this may be when javascript clients are relevant.

Rob

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric [Eric.Boisvert at RNCan-NRCan.gc.ca]
Sent: Monday, 9 August 2010 7:03 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] RE : URI resolution and javascript sandbox

So we need a resolver (which is the proxy application).

________________________________
De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Tellez-Arenas Agnes
Date: lun. 2010-08-09 03:14
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] URI resolution and javascript sandbox


Hi Eric

You can indeed use a proxy, but you don't need a specific "uri" proxy. You just need some web application that request any link you send to it and give you (give to the javascript) the response.
On 1G, Javascript request a simple page proxy.jsp?url=http://otherdomain/blabla/blabla

The only possibility to have cross-domain javascript is to use JSON (but I don't remember how!).

Agnès


-----Message d'origine-----
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Boisvert, Eric Envoyé : dimanche 8 août 2010 19:58 À : auscope-geosciml at lists.arcs.org.au
Objet : [auscope-geosciml] URI resolution and javascript sandbox


Sorry for the technical question here, I hope some programmers on the list (Ben ? Agnès ?) can tell me what they think.

I'm trying to implement a test case where a web client would read a GeoSciML file loaded with URI references.  I tried to implement something in javascript that could defer those reference and do something with them.  But I've been stopped by the fact that Javascript runs into a security sandbox that prevents it from dynamically reading from any other domain than the one the page comes from.  There are tricks to circumvert this problem

http://usejquery.com/posts/9/the-jquery-cross-domain-ajax-guide

the most straighforward is to implement a server proxy (all the solution are some sorts of proxies anyway).  Anyway, bottom line is that http URI in a web environment cannot be used as is (unless the web application happens to be at the same place, which is unlikely because we expect URI from various places) and therefore does not resolve (no pun intended) the resource deference problem (you need a proxy) at least in a WEB application, which is likely to be the most common one (1G portal comes to mind)

Now, I remember the great debates about URN and location of the resolver.  Doesn't sandbox restriction kind of impose where this resolver should be ?.  we need to configure a proxy anyway, which is not terribly different from configuring a resolver location ....

just a though.  Am I missing something ?

Eric





<http://usejquery.com/posts/9/the-jquery-cross-domain-ajax-guide>


_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
**********************************************************************************************
Pensez a l'environnement avant d'imprimer ce message Think Environment before printing

Le contenu de ce mel et de ses pieces jointes est destine a l'usage exclusif du (des) destinataire(s) designe
(s) comme tel(s).
En cas de reception par erreur, le signaler e son expediteur et ne pas en divulguer le contenu.
L'absence de virus a ete verifiee e l'emission, il convient neanmoins de s'assurer de l'absence de contamination a sa reception.

The contents of this email and any attachments are confidential. They are intended for the named recipient
(s) only.
If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
**********************************************************************************************
Pensez a l'environnement avant d'imprimer ce message
Think Environment before printing

Le contenu de ce mel et de ses pieces jointes est destine a l'usage exclusif du (des) destinataire(s) designe
(s) comme tel(s).
En cas de reception par erreur, le signaler e son expediteur et ne pas en divulguer le contenu.
L'absence de virus a ete verifiee e l'emission, il convient neanmoins de s'assurer de l'absence de
contamination a sa reception.

The contents of this email and any attachments are confidential. They are intended for the named recipient
(s) only.
If you have received this email in error please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10087 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100810/fee5819e/attachment.bin>


More information about the GeoSciML mailing list