Hi, The IGE project has implemented GLUE publication for some globus services, and would like to register the following type names: InterfaceName_t 'org.globus.gram' and 'org.globus.gsissh' PolicyScheme_t 'org.globus.standard' ServiceType_t 'org.globus.gram' and 'org.globus.gsissh' Do we have any problem with that? Stephen -- Scanned by iCritical.
Greetings Stephen, My only though was whether either the InterfaceName, or more likely the ServiceType, should indicate "gram5" instead of "gram" to help differentiate between the various generations of gram, now all of which are compatible. JP On Jul 22, 2013, at 10:56 AM, <stephen.burke@stfc.ac.uk> wrote:
Hi,
The IGE project has implemented GLUE publication for some globus services, and would like to register the following type names:
InterfaceName_t 'org.globus.gram' and 'org.globus.gsissh' PolicyScheme_t 'org.globus.standard' ServiceType_t 'org.globus.gram' and 'org.globus.gsissh'
Do we have any problem with that?
Stephen
-- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
My only concern is that these names should come from implementor of the services/interfaces, not from users. Did the IGE project developed these services by themselves, or it's globus services? also a serviceType org.globus.gsissh sounds very weird to me. All in all this repetition of names between Services and InterfaceNames makes me think we have no common understanding of the concepts. Here it seems there is a 1 to 1 relationship between Service and Endpoint. Is it so? Service for me is some kind of grouping of endpoints dedicated to to something, that's why we have ComputingService and StorageService. Moreover, we should only accept Open Enumerations that come with a description. Can they provide such a thing? Cheers, Florido On 2013-07-22 18:07, JP Navarro wrote:
Greetings Stephen,
My only though was whether either the InterfaceName, or more likely the ServiceType, should indicate "gram5" instead of "gram" to help differentiate between the various generations of gram, now all of which are compatible.
JP
On Jul 22, 2013, at 10:56 AM, <stephen.burke@stfc.ac.uk> wrote:
Hi,
The IGE project has implemented GLUE publication for some globus services, and would like to register the following type names:
InterfaceName_t 'org.globus.gram' and 'org.globus.gsissh' PolicyScheme_t 'org.globus.standard' ServiceType_t 'org.globus.gram' and 'org.globus.gsissh'
Do we have any problem with that?
Stephen
-- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Florido Paganelli said: My only concern is that these names should come from implementor of the services/interfaces, not from users. Did the IGE project developed these services by themselves, or it's globus services?
IGE are developers, not users (Initiative for Globus in Europe, now called something else I think): http://www.ige-project.eu/
also a serviceType org.globus.gsissh sounds very weird to me. All in all this repetition of names between Services and InterfaceNames makes me think we have no common understanding of the concepts.
I don't think we do have a clear understanding of the ServiceType, but nevertheless we have to publish something, it's a mandatory attribute. For Services which only have one type of Endpoint, copying the InterfaceName seems the simplest solution.
Here it seems there is a 1 to 1 relationship between Service and Endpoint. Is it so? Service for me is some kind of grouping of endpoints dedicated to to something, that's why we have ComputingService and StorageService.
The structure of the schema is that an Endpoint must have an associated Service, so we have to publish it like that even if there is only a single Endpoint (as is quite often the case).
Moreover, we should only accept Open Enumerations that come with a description. Can they provide such a thing?
I assume Tilo can do that, although gram and gsissh are well-known. Stephen -- Scanned by iCritical.
On 2013-07-22 18:29, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Florido Paganelli said: My only concern is that these names should come from implementor of the services/interfaces, not from users. Did the IGE project developed these services by themselves, or it's globus services?
IGE are developers, not users (Initiative for Globus in Europe, now called something else I think):
also a serviceType org.globus.gsissh sounds very weird to me. All in all this repetition of names between Services and InterfaceNames makes me think we have no common understanding of the concepts.
I don't think we do have a clear understanding of the ServiceType,
We created this. We must have.
but nevertheless we have to publish something, it's a mandatory attribute.
please let's not do this. This will lead to a plethora of Services and Endpoint names we will never manage consistently.
For Services which only have one type of Endpoint, copying the InterfaceName seems the simplest solution.
In my opinion a "Service" is some piece of software or a collection of software packages providing functionalities in the form of Endpoints. One should ask herself: what is "running" my Endpoint? I think it the other way around: first comes the service, then the endpoint. Service is what you can do, Endpoint is how you do it
Here it seems there is a 1 to 1 relationship between Service and Endpoint. Is it so? Service for me is some kind of grouping of endpoints dedicated to to something, that's why we have ComputingService and StorageService.
The structure of the schema is that an Endpoint must have an associated Service, so we have to publish it like that even if there is only a single Endpoint (as is quite often the case).
Ok, so what is running such endpoints? are they run inside the same "container" or they are independent pieces of software?
Moreover, we should only accept Open Enumerations that come with a description. Can they provide such a thing?
I assume Tilo can do that, although gram and gsissh are well-known.
Yes but before that we should make up our mind , don't you think so? We should be able to give directions about descriptions. Regards, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
but nevertheless we have to publish something, it's a mandatory attribute.
please let's not do this.
We have already done it (five years ago), the schema is what it is. There is no point in discussing this, and I don't intend to waste my time on doing so. Stephen
Sorry for double posting, I sent only to Stephen by mistake. On 2013-07-22 19:05, stephen.burke@stfc.ac.uk wrote:
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
but nevertheless we have to publish something, it's a mandatory attribute.
please let's not do this.
We have already done it (five years ago), the schema is what it is. There is no point in discussing this, and I don't intend to waste my time on doing so.
Stephen
Correct me if I am wrong, but the concept of Service came later in Glue1. You did that for Glue1 5 years ago. I think is bad choice. It's not a waste of time and I feel a bit offended by such comment. It's actually a useless duplication of information to have both Service and Endpoint reporting the same string as ServiceType and IntefaceName, unless these services are completely decoupled and independent. We should *really* think what we want to represent with these concepts. I expressed my views in the previous email. Just to remind text in the GFD147: "The Service class enables unique identification of instances of these concepts [Endpoints and the other entities] participating in the provision of some *unified* capability." I don't know the globus technology so well, but I have the feeling these Endpoint provide some *unified* capability and should be tied together by a single Service. I am a newbie, please give me a description of these services and we'll discuss. The strings alone have no meaning to me. Regards, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
JP Navarro [mailto:navarro@mcs.anl.gov] said:
My only though was whether either the InterfaceName, or more likely the ServiceType, should indicate "gram5" instead of "gram" to help differentiate between the various generations of gram, now all of which are compatible.
Usually I would say not - we have the InterfaceVersion for that. For example SRM v1 and v2 are incompatible, but both have a Name of SRM. I think they should only have different names if they're really fundamentally different. Stephen -- Scanned by iCritical.
Usually I would say not - we have the InterfaceVersion for that. For example SRM v1 and v2 are incompatible, but both have a Name of SRM. I think they should only have different names if they're really fundamentally different.
Also, think about future compatibility as well as the past - even if gram 5 is totally different to any previous gram, could there be a gram 6 which is backward-compatible? If so you'd have to keep calling it gram5 which wouldn't be very elegant ... Stephen -- Scanned by iCritical.
On 2013-07-22 19:15, stephen.burke@stfc.ac.uk wrote:>> Usually I would say not - we have the InterfaceVersion for that. For
example SRM v1 and v2 are incompatible, but both have a Name of SRM. I think they should only have different names if they're really fundamentally different.
Also, think about future compatibility as well as the past - even if gram 5 is totally different to any previous gram, could there be a gram 6 which is backward-compatible? If so you'd have to keep calling it gram5 which wouldn't be very elegant ...
Stephen
I think is no point to force compatibility concepts in the schema. This will always be questionable. If we wanted to do that, there should have been dedicated fields representing compatibility. I think we should foster simplicity and intuition. If 5 is software/protocol/package version, it SHOULD NOT be in the InterfaceName, in my opinion. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
Sorry for the delayed response, but I agree that InterfaceName should not have a version if we have a separate version field. On Jul 23, 2013, at 3:16 AM, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
On 2013-07-22 19:15, stephen.burke@stfc.ac.uk wrote:>> Usually I would say not - we have the InterfaceVersion for that. For
example SRM v1 and v2 are incompatible, but both have a Name of SRM. I think they should only have different names if they're really fundamentally different.
Also, think about future compatibility as well as the past - even if gram 5 is totally different to any previous gram, could there be a gram 6 which is backward-compatible? If so you'd have to keep calling it gram5 which wouldn't be very elegant ...
Stephen
I think is no point to force compatibility concepts in the schema. This will always be questionable. If we wanted to do that, there should have been dedicated fields representing compatibility.
I think we should foster simplicity and intuition.
If 5 is software/protocol/package version, it SHOULD NOT be in the InterfaceName, in my opinion.
Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - EMI Project System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ================================================== _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
participants (3)
-
Florido Paganelli -
JP Navarro -
stephen.burke＠stfc.ac.uk