[saga-rg] The URL problem

[Andre Merzky]

Hi Mark, 

You are certainly right, URIs should and can't be compared
and translated, really.  They should be used as is. However,
that is exactly the problem.

To elaborate: our SAGA implementation binds to different
middleware layers at runtime.  As SAGA is supposed to
abstract the middleware details away from the end user, that
seems only sensible.

What that means is, obviously, that I can do job submissions
to different resources, utilizing different middleware
beneath the hood:

  saga::job_server js_a ("broker_a.remote.net");
  js_a.run_job ("/bin/date");

  saga::job_server js_b ("broker_b.remote.net");
  js_b.run_job ("/bin/date");

assume broker_a runs gram, broker_b runs unicore: that
details stays hidden from the developer, and end user, as it
should be.

Now, URLs and URIs break that for file copies.

  saga::directory d_a ("gsiftp://server_a.remote.net//data/");
  d_a.copy ("1.dat", "2.dat);

  saga::directory d_a ("ftp://server_b.remote.net//data/");
  d_b.copy ("1.dat", "2.dat);

In contrast to the job submission above, the end user must
be aware that server_a runs gridftp, server_b does not.
Although your statement is correct, it leaves that problem.

Now, we could just ignore it, and leave the burden to the
end user.  That is what we did in GAT (which is similar to
SAGA in some respect), but the end users have been rather
unhappy about this, as that quite immediately destroys the
flexibility the API otherwise provides.

We also could rely on the availability of grid file systems,
which removes that problem due to a global addressing
scheme.  However, GFS's are not widely deployed as of yet,
so that would be overly idealistic.

Or we can try to provide workarounds, and that is what the
'any' scheme is supposed to be, really.  Its not a new
scheme in fact, but a placeholder, which is supposed to be
filled by any suitable scheme, if possible.  we could also
use

  ...://remote.host.net/tmp/file

or such ;-)

Hmm, I am not sure if I said anything different to the
section in the intro really.  Anyway, what I wanted to say
is:

You are right, mapping is not supposed to be possible.  But
the problem is that mappings are _very_ useful
nevertheless...

Cheers, Andre.

PS.: sorry, I probably mix URLs and URIs all over the text.
     However, I think the problem holds for both.



Quoting [Mark Mc Keown] (Jun 12 2006):
> 
> I have started looking at the SAGA strawman document and wanted
> to comment on the section "The URL problem".
> 
> URL -> URI
> ----------
> 
> In many circumstances URI has replaced URL, see for example
> Web Arch (http://www.w3.org/TR/webarch/). URIs allow you
> to identify things for which there may not yet exist a 
> representation - for example an output file for job
> that has not started or http://host.net/tmp/file in the
> SAGA document. 
> 
> 
> Comparing URIs
> --------------
> 
> Rules for comparing URIs are scheme dependent, so you cannot
> compare a ftp URI to http URI, see 
> http://www.textuality.com/tag/uri-comp-4 and 
> http://www.faqs.org/rfcs/rfc2396.html. The SAGA document effectively
> says this but I am not sure there is any need to go beyond saying
> you cannot compare URIs from different schemes. 
> 
> Two URIs with different schemes can identify the same resource, 
> ie they are aliases, but you cannot tell this from comparing the 
> URIs. However redirection may be used to relate the URIs. For example 
> a HTTP redirect: a user may get a 3XX response when attempting to
> retrieve a representation of resource using HTTP which 
> points him to a FTP server. So there is a question of how 
> SAGA would handle a redirection - redirection of POST or PUT
> in HTTP requires user input.
> 
> any scheme
> ----------
> 
> The W3C recommends not inventing schemes, section 2.4 of
> Web Arch.
>   
> 
> cheers
> Mark
> 



-- 
"So much time, so little to do..."  -- Garfield