Suggested errata to the SD spec

older
Multiple contexts of the same type

Steve Fisher

15 Apr 2009 15 Apr '09

10:35 a.m.

Hi, We would like to get rid of the URL passed into the discoverer constructor. Its comment is: "the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried" The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter. This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer. The constructor then just has the session handle The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased Steve

Show replies by date

Andre Merzky

15 Apr 15 Apr

10:48 a.m.

Hi Steve, Quoting [Steve Fisher] (Apr 15 2009):

...

Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

...

This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO. I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests. OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above. What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer? Thanks, Andre.

...

The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

Steve Fisher

12:54 p.m.

2009/4/15 Andre Merzky :

...

Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this. The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call. I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ... Steve

...

...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

Andre Merzky

1:30 p.m.

Quoting [Steve Fisher] (Apr 15 2009):

...

2009/4/15 Andre Merzky :

...
Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ...

In that case, don't use an URL for the API call. Then you can fall back to the configure file option you mentioned. The URL is supposed to be specified if the end user expects exactly *one* endpoint to be used. For example, I would specify a gram URL if I know I'll only submit jobs to that GRAM instance. That additionally saves the implementation the hazzle to try other adaptors, wnd thus improves performance. I still don't see where you think it is broken, as the URL is optional. Why would removing the URL arg any difference compared to just leaving it out in the API call? Thanks, Andre.

...

Steve

...
...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

-- Nothing is ever easy.

Steve Fisher

4:17 p.m.

Andre, I agree that it will work fine with exactly one adapter. However if he tries on a system with multiple adapters then it will be very inefficient and he will get lets of odd errors just because there are some adapters that he does not know about. I assume that this software will be installed by sysadmins on behalf of the users - and so on a multi-user machine there will normally be many adapters. If you think that this is "reasonable" behaviour then no change is needed. Steve 2009/4/15 Andre Merzky :

...

Quoting [Steve Fisher] (Apr 15 2009):

...
2009/4/15 Andre Merzky :

...
Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ...

In that case, don't use an URL for the API call. Then you can fall back to the configure file option you mentioned.

The URL is supposed to be specified if the end user expects exactly *one* endpoint to be used. For example, I would specify a gram URL if I know I'll only submit jobs to that GRAM instance. That additionally saves the implementation the hazzle to try other adaptors, wnd thus improves performance.

I still don't see where you think it is broken, as the URL is optional. Why would removing the URL arg any difference compared to just leaving it out in the API call?

Thanks, Andre.

...
Steve

...
...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

-- Nothing is ever easy.

Andre Merzky

4:43 p.m.

Sorry, Steve, I feel embarassed, but I don't get your point :-( Please bear with me, and allow me to draw some use cases in pseudo code. 1: with URL specified: When you do discoverer d ("glite://cern.ch"); list = d.discover (...); and you have 5 adaptors (made up list) glite mds local unicore condor then you get a valid response from the glite adaptor. You get no errors from the other adaptors, and no time overhead to speak off. 2: w/o URL specified When you do discoverer d (); list = d.discover (...); and you have 5 adaptors (made up list) glite mds local unicore condor then you get a valid response from the *each* adaptor, and the results are collated in the list. The endpoints to be contacted by each adaptor are configured on compile time, or via a config file, or environment. That is copletely implementation specific. I take it is case 1 you worry about, right? I don't see yet why - where do you think you would get confusing errors, or where do you think we get overhead? About overhead: invoking adaptors to check a URL costs next to nothing if compared to any remote call. Thanks, Andre. Quoting [Steve Fisher] (Apr 15 2009):

...

Andre,

I agree that it will work fine with exactly one adapter. However if he tries on a system with multiple adapters then it will be very inefficient and he will get lets of odd errors just because there are some adapters that he does not know about. I assume that this software will be installed by sysadmins on behalf of the users - and so on a multi-user machine there will normally be many adapters.

If you think that this is "reasonable" behaviour then no change is needed.

Steve

2009/4/15 Andre Merzky :

...
Quoting [Steve Fisher] (Apr 15 2009):

...
2009/4/15 Andre Merzky :

...
Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ...

In that case, don't use an URL for the API call. Then you can fall back to the configure file option you mentioned.

The URL is supposed to be specified if the end user expects exactly *one* endpoint to be used. For example, I would specify a gram URL if I know I'll only submit jobs to that GRAM instance. That additionally saves the implementation the hazzle to try other adaptors, wnd thus improves performance.

I still don't see where you think it is broken, as the URL is optional. Why would removing the URL arg any difference compared to just leaving it out in the API call?

Thanks, Andre.

...
Steve

...
...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

-- Nothing is ever easy.

-- Nothing is ever easy.

Hartmut Kaiser

6:15 p.m.

...

Sorry, Steve, I feel embarassed, but I don't get your point :-( Please bear with me, and allow me to draw some use cases in pseudo code.

1: with URL specified:

When you do

discoverer d ("glite://cern.ch"); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the glite adaptor. You get no errors from the other adaptors, and no time overhead to speak off.

2: w/o URL specified

When you do

discoverer d (); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the *each* adaptor, and the results are collated in the list. The endpoints to be contacted by each adaptor are configured on compile time, or via a config file, or environment. That is copletely implementation specific.

I take it is case 1 you worry about, right? I don't see yet why - where do you think you would get confusing errors, or where do you think we get overhead?

About overhead: invoking adaptors to check a URL costs next to nothing if compared to any remote call.

One thing we still didn't implement in the engine is the possibility to attach (query) multiple adaptors for the very same API call. We already discussed the necessity of such a thing but deferred its implementation. The candidate for this type of API calls we got inspired from is the sd::discoverer::discover :-P. But there might be more. I'm not sure, whether this is what Steve complains about, so please ignore this if not. Regards Hartmut

...

Thanks, Andre.

Quoting [Steve Fisher] (Apr 15 2009):

...
Andre,

I agree that it will work fine with exactly one adapter. However if

...
tries on a system with multiple adapters then it will be very inefficient and he will get lets of odd errors just because there are some adapters that he does not know about. I assume that this software will be installed by sysadmins on behalf of the users - and so on a multi-user machine there will normally be many adapters.

If you think that this is "reasonable" behaviour then no change is needed.

Steve

2009/4/15 Andre Merzky :

...
Quoting [Steve Fisher] (Apr 15 2009):

...
2009/4/15 Andre Merzky :

...
Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such

...
...
...
...
...
it can be queried"

The problem we have is that this does not work with an adapter

...
...
...
...
...
implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ...

In that case, don't use an URL for the API call. Then you can fall back to the configure file option you mentioned.

The URL is supposed to be specified if the end user expects exactly *one* endpoint to be used. For example, I would specify a gram URL if I know I'll only submit jobs to that GRAM instance. That additionally saves the implementation the hazzle to try other adaptors, wnd thus improves performance.

I still don't see where you think it is broken, as the URL is optional. Why would removing the URL arg any difference compared to just leaving it out in the API call?

Thanks, Andre.

...
Steve

...
...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with

he that based the

...
...
...
...
...
rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

-- Nothing is ever easy.

-- Nothing is ever easy. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg

Steve Fisher

7:32 p.m.

2009/4/15 Andre Merzky :

...

Sorry, Steve, I feel embarassed, but I don't get your point :-( Please bear with me, and allow me to draw some use cases in pseudo code.

1: with URL specified:

When you do

discoverer d ("glite://cern.ch"); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the glite adaptor. You get no errors from the other adaptors, and no time overhead to speak off.

Thanks for the concrete example. The gLite information system is based on the "BDII" and accepts ldap calls (ldap://...). According to http://globus.org/toolkit/mds/ the mds (in GT4) is WSRF based - so you need to talk SOAP not LDAP. You are sure to get a rude reply if you make an LDAP call to a WS or a SOAP call to an LDAP server. In some cases the adaptor could choose to ignore a URL with the wrong scheme (first part of the URL). gLite does not use gLite as the scheme part of the url but "ldap" and most services use "http" or "https" so there is no easy way for an adapter to recognise the validity of an info system URL. I hope this is clear now. Steve

...

2: w/o URL specified

When you do

discoverer d (); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the *each* adaptor, and the results are collated in the list. The endpoints to be contacted by each adaptor are configured on compile time, or via a config file, or environment. That is copletely implementation specific.

I take it is case 1 you worry about, right? I don't see yet why - where do you think you would get confusing errors, or where do you think we get overhead?

About overhead: invoking adaptors to check a URL costs next to nothing if compared to any remote call.

Thanks, Andre.

Quoting [Steve Fisher] (Apr 15 2009):

...
Andre,

I agree that it will work fine with exactly one adapter. However if he tries on a system with multiple adapters then it will be very inefficient and he will get lets of odd errors just because there are some adapters that he does not know about. I assume that this software will be installed by sysadmins on behalf of the users - and so on a multi-user machine there will normally be many adapters.

If you think that this is "reasonable" behaviour then no change is needed.

Steve

2009/4/15 Andre Merzky :

...
Quoting [Steve Fisher] (Apr 15 2009):

...
2009/4/15 Andre Merzky :

...
Hi Steve,

Quoting [Steve Fisher] (Apr 15 2009):

...
Hi,

We would like to get rid of the URL passed into the discoverer constructor. Its comment is:

"the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried"

The problem we have is that this does not work with an adapter based implementation as the URL is normally specific to the adapter.

I'm sorry, you lost me: why is that not working? The implementation should be able to forward the URL to the adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only make sense to one of them. For gLite it would point to some BDII server which provides information for gLite. No other adapter is likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically only one adapter can actually be expected to respond sensibly and accept the job it is given. Even if you have used Service Discovery to get the URL of the Job Service to use the saga engine will still have to cycle through making calls to all the adaptors ahead of the one that is going to work for you. So in this case you really want to be able to dynamically influence the sequence of adaptors to avoid a load of wasted network calls - and timeout delays ...

In that case, don't use an URL for the API call. Then you can fall back to the configure file option you mentioned.

The URL is supposed to be specified if the end user expects exactly *one* endpoint to be used. For example, I would specify a gram URL if I know I'll only submit jobs to that GRAM instance. That additionally saves the implementation the hazzle to try other adaptors, wnd thus improves performance.

I still don't see where you think it is broken, as the URL is optional. Why would removing the URL arg any difference compared to just leaving it out in the API call?

Thanks, Andre.

...
Steve

...
...
This information can be passed to the adapter using a configuration file or an environment variable according to the style adpopted by the adaper writer.

That is an orthogonal issue IMHO.

I would like to compare that to the job::service, where we give a contact URL for the job submission endpoint. That URL is adaptor specific, e.g. it could be 'gram://remote.globus.host:123/'. That URL would then be forwarded to the adaptors. Only the globus adaptor would accept it, and act on job submission requests.

OTOH, if the URL is not specified (it is optional in te API), then a default URL from the adaptor configuration files is used. That could also be an env variable, as you state above.

What is the problem with that scheme? Seems to work for job::service and other classes - why not for the service discoverer?

Thanks, Andre.

...
The constructor then just has the session handle

The other change is to make the attribute names consistent with the rest of SAGA - i.e. CamelCased

Steve -- Nothing is ever easy.

-- Nothing is ever easy.

-- Nothing is ever easy.

Andre Merzky

8:10 p.m.

Quoting [Steve Fisher] (Apr 15 2009):

...

...
1: with URL specified:

When you do

discoverer d ("glite://cern.ch"); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the glite adaptor. You get no errors from the other adaptors, and no time overhead to speak off.

Thanks for the concrete example. The gLite information system is based on the "BDII" and accepts ldap calls (ldap://...). According to http://globus.org/toolkit/mds/ the mds (in GT4) is WSRF based - so you need to talk SOAP not LDAP. You are sure to get a rude reply if you make an LDAP call to a WS or a SOAP call to an LDAP server. In some cases the adaptor could choose to ignore a URL with the wrong scheme (first part of the URL). gLite does not use gLite as the scheme part of the url but "ldap" and most services use "http" or "https" so there is no easy way for an adapter to recognise the validity of an info system URL.

I hope this is clear now.

Yes, a lot clearer, thanks! At last I think we are getting on the same page - thanks for your patience! :-) So, a given URL can lead to problems if more than one adaptor feel able to handle it. (BTW: the failing adaptors would *not* cause an exception on API level, as long as one adaptor succeeds.) Removing the URL surely would solve the problem. But, as said, the URL is optional anyway. What is the gain? Also, the glite adaptor is free to define the schema glite://, and translate that internally to ldap://. We do that, for example, with gridftp, which is translated to gsiftp. Also, we do that for ssh:// URLs, which are translated into local file URLS (for sshfs mounted file systems). I am not saying that you should not remove the URL - just want to make sure I understand why the URL is a problem, really. Best, Andre. -- Nothing is ever easy.

Steve Fisher

16 Apr 16 Apr

9:03 a.m.

2009/4/15 Andre Merzky :

...

Quoting [Steve Fisher] (Apr 15 2009):

...
...
1: with URL specified:

When you do

discoverer d ("glite://cern.ch"); list = d.discover (...);

and you have 5 adaptors (made up list)

glite mds local unicore condor

then you get a valid response from the glite adaptor. You get no errors from the other adaptors, and no time overhead to speak off.

Thanks for the concrete example. The gLite information system is based on the "BDII" and accepts ldap calls (ldap://...). According to http://globus.org/toolkit/mds/ the mds (in GT4) is WSRF based - so you need to talk SOAP not LDAP. You are sure to get a rude reply if you make an LDAP call to a WS or a SOAP call to an LDAP server. In some cases the adaptor could choose to ignore a URL with the wrong scheme (first part of the URL). gLite does not use gLite as the scheme part of the url but "ldap" and most services use "http" or "https" so there is no easy way for an adapter to recognise the validity of an info system URL.

I hope this is clear now.

Yes, a lot clearer, thanks! At last I think we are getting on the same page - thanks for your patience! :-)

So, a given URL can lead to problems if more than one adaptor feel able to handle it.

Yes!

...

Removing the URL surely would solve the problem. But, as said, the URL is optional anyway. What is the gain?

OK - I am to keep it in the spec

...

Also, the glite adaptor is free to define the schema glite://, and translate that internally to ldap://. We do that, for example, with gridftp, which is translated to gsiftp. Also, we do that for ssh:// URLs, which are translated into local file URLS (for sshfs mounted file systems).

I think that SAGA adapters should not require changes to the underlying middleware so I don't like this idea.

...

I am not saying that you should not remove the URL - just want to make sure I understand why the URL is a problem, really.

Having had this discussion I now feel that the problem with the SD is not serious however making proper use of the returned URLs is a problem for all the other SAGA components. It is however an implementation problem so I will move it to the developers list. Nobody commented on the CamelCased attribute names - I would propose to change all out attribute names in the spec to be CamelCased like the rest of SAGA and to change the Java and C++ now to match. We want to get the code released rather soon into gLite. Steve

...

Best, Andre.

-- Nothing is ever easy.

Andre Merzky

9:07 a.m.

Quoting [Steve Fisher] (Apr 16 2009):

...

...
Also, the glite adaptor is free to define the schema glite://, and translate that internally to ldap://. We do that, for example, with gridftp, which is translated to gsiftp. Also, we do that for ssh:// URLs, which are translated into local file URLS (for sshfs mounted file systems).

I think that SAGA adapters should not require changes to the underlying middleware so I don't like this idea.

The change (i.e. URL translation) is in the adaptor, not in the middleware. the middleware is not touched. I completely agree that this would be a NO-NO.

...

...
I am not saying that you should not remove the URL - just want to make sure I understand why the URL is a problem, really.

Having had this discussion I now feel that the problem with the SD is not serious however making proper use of the returned URLs is a problem for all the other SAGA components. It is however an implementation problem so I will move it to the developers list.

agree.

...

Nobody commented on the CamelCased attribute names - I would propose to change all out attribute names in the spec to be CamelCased like the rest of SAGA and to change the Java and C++ now to match. We want to get the code released rather soon into gLite.

+1 I guess that no comment simply means silent agreemen :-) Thanks, Andre. -- Nothing is ever easy.

5651

Age (days ago)

5652

Last active (days ago)

List overview

Download

10 comments

3 participants

participants (3)

Andre Merzky
Hartmut Kaiser
Steve Fisher