The minutes of the last meeting have been added to the wiki. The next meeting is scheduled for 16:00 CET on Friday 5th June. There were three items that require attention and have been highlighted in this mail. 1) The placement of Foreign Keys was discussed and the result is documented on the following page. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/LDAPFor... Unless anyone has any disagreements, what is currently document will be taken as the official result by the end of the next meeting. 2) It was also agree that need to have a fixed root entry for the DN, however, we still need some inspiration on what this should be. o=grid, o=glue, etc. 3) The Grouping discussions requires input from Balazs. If the DIT is enforced, most use cases can be met by doing a subtree query. However, there may still be a need for a generic grouping object. If the DIT is enforced we need to define where this object is placed. Regards, Laurence
The LDAP schema has been updated with the current status of the Foreign Keys. You can take a look at: http://forge.ogf.org/svn/repos/glue/LDAP2/schema/ I am currently going to update the basic tests and create new ones for them. If anybody wants to help, do not hesitate to email me. Regards, David 2009/6/3 Laurence Field <Laurence.Field@cern.ch>
The minutes of the last meeting have been added to the wiki. The next meeting is scheduled for 16:00 CET on Friday 5th June. There were three items that require attention and have been highlighted in this mail.
1) The placement of Foreign Keys was discussed and the result is documented on the following page.
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/LDAPFor...
Unless anyone has any disagreements, what is currently document will be taken as the official result by the end of the next meeting.
2) It was also agree that need to have a fixed root entry for the DN, however, we still need some inspiration on what this should be. o=grid, o=glue, etc.
3) The Grouping discussions requires input from Balazs. If the DIT is enforced, most use cases can be met by doing a subtree query. However, there may still be a need for a generic grouping object. If the DIT is enforced we need to define where this object is placed.
Regards,
Laurence
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Fax +41 22 76 68178 (fax to email service) Web: http://cern.ch/horat Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
Agenda for today's conference has been updated: http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMe... Regards, David On Wed, Jun 3, 2009 at 1:19 PM, David Horat <david.horat@cern.ch> wrote:
The LDAP schema has been updated with the current status of the Foreign Keys. You can take a look at: http://forge.ogf.org/svn/repos/glue/LDAP2/schema/
I am currently going to update the basic tests and create new ones for them. If anybody wants to help, do not hesitate to email me.
Regards, David
2009/6/3 Laurence Field <Laurence.Field@cern.ch>
The minutes of the last meeting have been added to the wiki. The next
meeting is scheduled for 16:00 CET on Friday 5th June. There were three items that require attention and have been highlighted in this mail.
1) The placement of Foreign Keys was discussed and the result is documented on the following page.
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/LDAPFor...
Unless anyone has any disagreements, what is currently document will be taken as the official result by the end of the next meeting.
2) It was also agree that need to have a fixed root entry for the DN, however, we still need some inspiration on what this should be. o=grid, o=glue, etc.
3) The Grouping discussions requires input from Balazs. If the DIT is enforced, most use cases can be met by doing a subtree query. However, there may still be a need for a generic grouping object. If the DIT is enforced we need to define where this object is placed.
Regards,
Laurence
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Fax +41 22 76 68178 (fax to email service) Web: http://cern.ch/horat Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Fax +41 22 76 68178 (fax to email service) Web: http://cern.ch/horat Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: 2) It was also agree that need to have a fixed root entry for the DN, however, we still need some inspiration on what this should be. o=grid, o=glue, etc.
Google finds me this, which is at least amusing! http://www.zytrax.com/books/ldap/apa/ldap-root.html Stephen -- Scanned by iCritical.
Ok guys, a generic grouping object has been added to the schemas and tests: http://forge.ogf.org/svn/repos/glue/LDAP2/schema/01-Grouping.schema http://forge.ogf.org/svn/repos/glue/LDAP2/ldif/01-Grouping.ldif Regards, David On Fri, Jun 5, 2009 at 4:41 PM, Burke, S (Stephen) <stephen.burke@stfc.ac.uk
wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: 2) It was also agree that need to have a fixed root entry for the DN, however, we still need some inspiration on what this should be. o=grid, o=glue, etc.
Google finds me this, which is at least amusing!
http://www.zytrax.com/books/ldap/apa/ldap-root.html
Stephen -- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Fax +41 22 76 68178 (fax to email service) Web: http://cern.ch/horat Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
david.horat@gmail.com [mailto:david.horat@gmail.com] On Behalf Of David Horat said:
Ok guys, a generic grouping object has been added to the schemas and tests:
I would be inclined to call it "Group" rather than "Grouping", although it isn't all that important. Also I don't think the ID needs to be globally unique and generally I'd expect it not to be - it should never appear in any queries or relations since it isn't a primary GLUE object (except that it could be used to restrict the subtree in a query, but it only needs to be locally unique for that). Stephen -- Scanned by iCritical.
Burke, S (Stephen) wrote:
I would be inclined to call it "Group" rather than "Grouping", although
Agreed.
it isn't all that important. Also I don't think the ID needs to be globally unique and generally I'd expect it not to be - it should never appear in any queries or relations since it isn't a primary GLUE object (except that it could be used to restrict the subtree in a query, but it only needs to be locally unique for that).
I would still recommend a globally unique ID: I thought we were going to have that everywhere?
Maarten Litmaath [mailto:Maarten.Litmaath@cern.ch] said:
I would still recommend a globally unique ID: I thought we were going to have that everywhere?
Well, except for Extension. But the reason to have unique IDs for objects is so you can refer to them directly, e.g. in glue 1 you can't refer to an SA without specifying the SEUniqueID as well. For the Group objects there should be no need to refer to them at all. The downside of a unique id is that you have to have some algorithm to construct it, which is likely to be done by concatenating various elements which will probably make it rather long (look at the current CEIds). Stephen -- Scanned by iCritical.
Burke, S (Stephen) wrote:
I would still recommend a globally unique ID: I thought we were going to have that everywhere?
Well, except for Extension. But the reason to have unique IDs for objects is so you can refer to them directly, e.g. in glue 1 you can't refer to an SA without specifying the SEUniqueID as well. For the Group objects there should be no need to refer to them at all. The downside of a unique id is that you have to have some algorithm to construct it, which is likely to be done by concatenating various elements which will probably make it rather long (look at the current CEIds).
OK, then groups should have "local" IDs instead.
participants (4)
-
Burke, S (Stephen) -
David Horat -
Laurence Field -
Maarten Litmaath