I'm working on a suite of programs (actually two servers and one gui
app) which share a setting file. The thing is that I'd like to put this
shared setting file somewhere privately (currently it's in C:\), but
accessible to these three programs. The only way I can see this possible
is extending their capabilities (AllFiles). Is this true, or is there
any better alternative?
--
David Caabeiro
www.PushL.com
"David Caabeiro" <[email protected]> wrote in message
news:8MildClBGHA.1040@extapps30...
> I'm working on a suite of programs (actually two servers and one gui app)
> which share a setting file. The thing is that I'd like to put this shared
> setting file somewhere privately (currently it's in C:\), but accessible
> to these three programs. The only way I can see this possible is extending
> their capabilities (AllFiles). Is this true, or is there any better
> alternative?
You could make it private to one of your servers and add an API for
accessing it to that server. That's probably necessary anyway because all
three programs could try to access the file at the same time.
--
Sander van der Wal
www.mBrainSoftware.com
Sander van der Wal wrote:
> "David Caabeiro" <[email protected]> wrote in message
> news:8MildClBGHA.1040@extapps30...[color=green]
>> I'm working on a suite of programs (actually two servers and one gui app)
>> which share a setting file. The thing is that I'd like to put this shared
>> setting file somewhere privately (currently it's in C:\), but accessible
>> to these three programs. The only way I can see this possible is extending
>> their capabilities (AllFiles). Is this true, or is there any better
>> alternative?
>
> You could make it private to one of your servers and add an API for
> accessing it to that server. That's probably necessary anyway because all
> three programs could try to access the file at the same time.
>[/color]
I have a similar requirement. Sander, is there a simpler way. My
requirement is for read only access and I will make sure the access
doesn't clash. Is there a public location I can put my settings file,
it's not really confidential so I don't mind if someone sees it too.
Thanks, AMK
>>I'm working on a suite of programs (actually two servers and one gui app)[color=green]
>>which share a setting file. The thing is that I'd like to put this shared
>>setting file somewhere privately (currently it's in C:\), but accessible
>>to these three programs. The only way I can see this possible is extending
>>their capabilities (AllFiles). Is this true, or is there any better
>>alternative?
>
>
> You could make it private to one of your servers and add an API for
> accessing it to that server. That's probably necessary anyway because all
> three programs could try to access the file at the same time.[/color]
The problem is that none of the servers are required to be loaded. So
creating an explicit connection to read some settings seems excesive..
Also, locking is already provided so that's not an issue.
At first, I thought that using the same SECUREID (and three different
UIDs) for all three programs would provide this 'suite', but it's not
the case.
--
David Caabeiro
www.PushL.com
> I have a similar requirement. Sander, is there a simpler way. My
> requirement is for read only access and I will make sure the access
> doesn't clash. Is there a public location I can put my settings file,
> it's not really confidential so I don't mind if someone sees it too.
With the exception of \sys , \private and \resource, all other locations
are public, so you may access them freely (ie. no need of capability)
--
David Caabeiro
www.PushL.com
David Caabeiro wrote:[color=green][color=darkred]
>>> I'm working on a suite of programs (actually two servers and one gui
>>> app) which share a setting file. The thing is that I'd like to put
>>> this shared setting file somewhere privately (currently it's in C:\),
>>> but accessible to these three programs. The only way I can see this
>>> possible is extending their capabilities (AllFiles). Is this true, or
>>> is there any better alternative?
>>
>>
>> You could make it private to one of your servers and add an API for
>> accessing it to that server. That's probably necessary anyway because
>> all three programs could try to access the file at the same time.[/color]
>
> The problem is that none of the servers are required to be loaded. So
> creating an explicit connection to read some settings seems excesive..
> Also, locking is already provided so that's not an issue.
> At first, I thought that using the same SECUREID (and three different
> UIDs) for all three programs would provide this 'suite', but it's not
> the case.
>[/color]
No, every exe needs a unique secure id I think. Anyway, we tried the SID
approach it won't work 😞
AMK
"David Caabeiro" <[email protected]> wrote in message
news:PbMEKqwBGHA.1908@extapps30...[color=green][color=darkred]
>>>I'm working on a suite of programs (actually two servers and one gui app)
>>>which share a setting file. The thing is that I'd like to put this shared
>>>setting file somewhere privately (currently it's in C:\), but accessible
>>>to these three programs. The only way I can see this possible is
>>>extending their capabilities (AllFiles). Is this true, or is there any
>>>better alternative?
>>
>>
>> You could make it private to one of your servers and add an API for
>> accessing it to that server. That's probably necessary anyway because all
>> three programs could try to access the file at the same time.[/color]
>
> The problem is that none of the servers are required to be loaded. So
> creating an explicit connection to read some settings seems excesive..
> Also, locking is already provided so that's not an issue.
> At first, I thought that using the same SECUREID (and three different
> UIDs) for all three programs would provide this 'suite', but it's not the
> case.[/color]
Have you looked at Properties (Publish and Subscribe)?
--
Sander van der Wal
www.mBrainSoftware.com
> Have you looked at Properties (Publish and Subscribe)?
Yes, Central Repository seems to be the way to go, but I wanted to make
sure first there wasn't a more reusable and backward compatible way with
v < 9
--
David Caabeiro
www.PushL.com