Agree to you.
For the new option, we need a new ticket. We cannot fix it in this ticket.

Regards,
Zoran

-----Original Message-----
From: Anders Björnerstedt 
Sent: den 26 augusti 2014 15:38
To: Zoran Milinkovic; Anders Widell; Hans Feldt
Cc: [email protected]
Subject: RE: [devel] [PATCH 1 of 1] immtools: fix the use of extended names in 
immcfg [#980]

 I am back to the notion of having the tools controlled for long DNs by Both an 
environemnt variable and an option. The enviroment variable is A runtime 
environemnt variable, not a compile time define here. 

IF the envionment variable is defined then long DNs are by default allowed by 
the tool.
If the enviroment variable is not defined then long DNs are by default not 
allowed by the tool.
This will give natural backwards compatibility to a feature that is in general 
not backwards Compatible by its very nature.

The defaul can be overriden by a long-option where the default for the option 
is determined By the environment variable. 

Thus if you are running the old backwards compatible environemnt then the new 
environemnt variable is NOT defined and a tool will not expose you to long DNs 
unless you explicitly set --longDns=yes.
And if you are running the new enviorment where longDNs are allowed then the 
new environemnt variable is defined and a tool may expose you to long DNs 
unless you explicitly set --longDns=no

/AndersBj

-----Original Message-----
From: Anders Björnerstedt [mailto:[email protected]]
Sent: den 26 augusti 2014 15:01
To: Zoran Milinkovic; Anders Widell; Hans Feldt
Cc: [email protected]
Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of extended names in 
immcfg [#980]

 Again, I dont see backawards compatibility as an issue because if the 
application/deployment can not handle long DNs then they must not set the imm 
configuration attribute to allow long DNs. 

Worst case is if you have one application that needs long DNs and another 
application that does Not support long DNs, both running on the same site.
In that case you have to allow long DNs in the system. But the application that 
can not suport longDNs yet should have Ois that will automatically reject any 
attempt to create objects Or refrences with long DNs in their domain, because 
the callbacks will not even reach the OI and the CCB will get aborted (this 
even if the imm config attribute says long DNs are allowed).

And if out have some reader that iterates over several domains, some that have 
long DNs and some That dont, then that reader better be able to cope with long 
DNs. Or EXPLCITLY set an argument to the Tool tio filter out long DNs.

/AndersBj


-----Original Message-----
From: Zoran Milinkovic
Sent: den 26 augusti 2014 14:49
To: Anders Björnerstedt; Anders Widell; Hans Feldt
Cc: [email protected]; [email protected]
Subject: RE: [devel] [PATCH 1 of 1] immtools: fix the use of extended names in 
immcfg [#980]

This will not be backwards compatible change.
In this case, applications must change the usage of imm tools in their code and 
add the new option.

Best regards,
Zoran

-----Original Message-----
From: Anders Björnerstedt
Sent: den 26 augusti 2014 14:12
To: Anders Widell; Hans Feldt
Cc: Zoran Milinkovic; [email protected]; 
[email protected]
Subject: RE: [devel] [PATCH 1 of 1] immtools: fix the use of extended names in 
immcfg [#980]

In that case it should be an option to NOT allow long DNs and default (no 
option set) should be that the tool allows long DNs (the version of the tool 
that has been adapted to handle long DNs.

This since we are evolving in that direction.

/AndersBj  

-----Original Message-----
From: Anders Widell
Sent: den 26 augusti 2014 14:08
To: Anders Björnerstedt; Hans Feldt
Cc: Zoran Milinkovic; [email protected]; 
[email protected]
Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of extended names in 
immcfg [#980]


On 08/26/2014 02:00 PM, Anders Bjornerstedt wrote:
> Hans Feldt wrote:
>>> -----Original Message-----
>>> From: Anders Widell [mailto:[email protected]]
>>> Sent: den 26 augusti 2014 13:13
>>> To: Zoran Milinkovic; [email protected]
>>> Cc: [email protected]
>>> Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of 
>>> extended names in immcfg [#980]
>>>
>>> Hi!
>>>
>>> Two comments:
>>>
>>> 1) I suppose this bug exists in all tools, so they other ones also 
>>> need to be fixed?
>>>
>>> 2) Maybe the tools should always support long DNs, so that you don't 
>>> have to set the environment variable in the shell?
>> [Hans] why would you set env vars? The tool should instead have a new 
>> option
> Sure add an option also.
> But *if* you have set the environmentt variable and not set the option 
> then you should get the same result as if you had set the option and 
> not the environment-variable.
>
> I am assuming here you can not set the environment variable explicitly 
> to not allow long DNs.
> If that where the case then the two could conflict.
Hmm, I am still thinking, but here are my current thoughts. :-) The original 
intended meaning of the environment variable was to signal to the agent that 
the application has been adapted to support long DNs, by using saAisNameLend() 
and saAisNameBorrow() etc. We were even trying to find a way to avoid the need 
for the environment variable - i.e. to find a way for the agent to detect if 
the application has been compiled with the preprocessor macro defined or not. 
However, this turned out to be difficult and hence the environment variable was 
introduced.

So clearly with this reasoning the tools should set the environment variable 
since they have been adapted. But - you could by "application" 
actually mean something bigger than the tool, like the shell script which is 
using the tool. Then you could potentially run into problems. 
Maybe option is the way to go, as Hans suggests.

/ Anders Widell

>
> /AndersBj
>>> regards,
>>> / Anders Widell
>>>
>>> On 08/25/2014 03:44 PM, Zoran Milinkovic wrote:
>>>>   osaf/tools/safimm/immcfg/imm_cfg.c |  1 +
>>>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>>
>>>> The patch enables using osaf_extended_name_* functions in the 
>>>> correct way before the first saImmOmInitialize() is called.
>>>>
>>>> diff --git a/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> b/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> --- a/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> +++ b/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> @@ -1539,5 +1539,6 @@ static int imm_operation(int argc, char
>>>>   }
>>>>
>>>>   int main(int argc, char *argv[]) {
>>>> +    osaf_extended_name_init();
>>>>       return imm_operation(argc, argv);
>>>>   }
>>>>
>>>> -------------------------------------------------------------------
>>>> -----------
>>>>
>>>> Slashdot TV.
>>>> Video for Nerds.  Stuff that matters.
>>>> http://tv.slashdot.org/
>>>> _______________________________________________
>>>> Opensaf-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>>>
>>>>
>>> --------------------------------------------------------------------
>>> ----------
>>>
>>> Slashdot TV.
>>> Video for Nerds.  Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> Opensaf-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>
>> ---------------------------------------------------------------------
>> ---------
>>
>> Slashdot TV.  Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Opensaf-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to