Re: SCDynamicStoreAddTemporaryValue returns permissions denied error
Re: SCDynamicStoreAddTemporaryValue returns permissions denied error
- Subject: Re: SCDynamicStoreAddTemporaryValue returns permissions denied error
- From: Tomas Zahradnicky <email@hidden>
- Date: Sun, 1 Jun 2003 14:38:40 +0200
Hello Quinn,
however the result is always 0 and I get 1003 (permissions denied)
error. Do I have to run as root in order to do this or the error
might be elsewhere?
You need to be running as root in order to modify any SCF structures.
I guessed correctly. However that is not mentioned in the SCF
"overview". From "A client application can access, update, and
remove keys from the dynamic store." I understood that anyone may
access DS and doesn't need to run as root. Maybe it is an offending
sentence.
The choice of API for communicating between clients and a daemon is
complex. It depends on a number of factors, including:
o the structure of the daemon (is it "select" or CFRunLoop based).
My daemon app is the CFRunLoop based app (NSUIElement=1), which has
few run loop sources added to monitor processes deaths. It displays
GUI such as floating windows from it.
o the structure of the clients (are they GUI-based applications,
or UNIX tools, or whatever).
Clients are most likely GUI based. They are applications such as
iTunes, FileMaker etc. They load my scripting addition into their
context (if requested by scripter, of course) and I create a mach
port a mach port and bind it together with the app. When the app
dies, the mach port gets invalidated and callback fires as suggested
by TN.
o the communication frequency (the order of magnitude of the number
of communications per second between your clients and the daemon).
Well, this completely depends on the scripter. Some of the osax
routines require RPC to update the contents of windows and the most
critical things shared are in the shared memory block. The POSIX
shared memory [shmget, shmat, shmdt] uses
int=FOUR_CHAR_ID(my_creator) to distinguish the SHM block and it
might clash with someone elses app. If I clash I can only tell,
"Unable cannot allocate SHM" )-:
o the communication throughput (how many bytes of data will be
sent down the channel per second).
Not much. It might be up to 1K/s, but it has to be fast since users
are unlikely to wait with spinning disc.
o the number of distinct operations (for example, if the clients can
only tell the daemon to do one thing, then a non-RPC based
communication makes sense; OTOH, if there are hundreds of distinct
messages between the client and the daemon, it would behoove you
to use some sort of RPC mechanism, such as MIG)
Well in fact there're two types of messages.
- AE based. This one forwards events from the host to the daemon
and gets response back.
- Settings one. Stored in SHM and I don't like it. I'd like to make
it better.
If you supply some details, I can offer some more specific advice.
OK. Is the above info sufficient?
PS: Quinn, how's going the SCF documentation project?
I have no new information on this )-:
Unfortunately, I expected that :-\
Thanks,
-Tomas
--
Ing. Tomas Zahradnicky, Jr.
Production Manager, 24U Software
Associate Member, Filemaker Solutions Alliance
mailto:email@hidden
http://www.24uSoftware.com
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.