[omniORB] OmniNames patch

[Alex Tingle]

Hi Jorge,

omniEvents used to have exactly the same behaviour, and I too was 
dissatisfied with it. I changed omniEvents to treat its "-start" 
parameter (actually -p) like this:

  If there is no logfile then create one.

  If there is a logfile and the port in the file matches the start 
parameter, then start up as normal: ignore the parameter.

  If there is a logfile and the port in the file DOES NOT match the 
start parameter, then quit with an error.

I feel that this gets the balance right between convenience and 
preserving the way it works now.

-Alex

--
Dammit Jim, I'm a programmer... not a mind reader!
On 7 Sep 2005, at 12:01, jorgefm at cirsa.com wrote:

> Well, the only thing I dislike from the current behaviour
> is the error that omniNames generates now. I prefer to
> have a known initial situation in my embedded device when
> he boots, and an option, is to recreate the log file every
> time.
>
> I would prefer that if the log is present omniNames would use
> it, and if the log doesn't exists omniNames would create it,
> avoiding the need of the parameters. But my solution is more easy
> to integrate in the existing code.
>
>> than once? Once you've created the database, why do you want to
>> re-create it?
>>
>
> Alex Tingle <alex.tingle at bronermetals.com> escribió el 07/09/2005
> 12:39:18:
>
>> Um, why do you want to use omniNames with the -start parameter more
>> than once? Once you've created the database, why do you want to
>> re-create it?
>>
>> -Alex
>>
>> --
>> Dammit Jim, I'm a programmer... not a mind reader!
>> On 7 Sep 2005, at 11:19, jorgefm at cirsa.com wrote:
>>
>>> Hi all,
>>>
>>> I've made a little patch to omniNames from the omniORB 4.0.6, that I
>>> would
>>> like to be included in the main branch if it is useful for you.
>>>
>>> The patch tries to address the problem that I've always that I try
> to
>>> execute the omniNames. I've change the -start parameter behaviour.
>>>
>>> 1) When the -start is used, I delete the old log files instead of
>>> generating
>>> an error, but this can be controlled using the 'removelogs'
> constructor
>>> argument.
>>>
>>> 2) The permission given to the logs files are RW for all (owner,
> group
>>> and others)
>>>
>>> Thanks for your comments,
>>> Jorge
>>>
>>> (Ver archivo anexo: omniNames-4.0.6-patch)
>>>
>>>
> <omniNames-4.0.6-patch>_______________________________________________
>>> omniORB-list mailing list
>>> omniORB-list at omniorb-support.com
>>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> <http://www.omniorb-support.com/mailman/listinfo/omniorb-list>
>>
>
>