- While my app is running it makes some changes to the configuration,
for example, creates or deletes a file.

On Aug 13, 8:10 am, neelsm... at (no spam) rediffmail.com wrote:
I am not sure how I can do this. Use dbus but use my own daemon?

Exactly. Use your own dbus daemon. That way, you are not dependent on
the system running a dbus daemon.

On Aug 13, 8:10 am, neelsm... at (no spam) rediffmail.com wrote:
I am not sure how I can do this. Use dbus but use my own daemon?

Exactly. Use your own dbus daemon. That way, you are not dependent on
the system running a dbus daemon.

On Aug 14, 2:55 am, Rainer Weikusat <rweiku... at (no spam) mssgmbh.com> wrote:

DO NOT DO THAT. If you want to use facilities provided by dbus, make
your application dependent on dbus being availabe on any system it is
supposed to run on. That's going to be a pain in the ass for everyone
except Fedore Core desktop users with fast (multicore?) desktop PCs
(slight xaggeration) , but still less of a nuisance than having twenty
different dbus-daemons running on the same system, each serving the
need of exactly one application and being based on a random, outdated
version of the dbus code base.

What is the advantage of *requiring* a system-installation of dbus?

Neel writes:
Yes, shared memory segment idea is I think what I am looking for.

A file would work as well.

So that, if I create, for the sake of it, a map of event vs. subscriber,
I should be able to create it in shared memory segment so that when my
app tries to find the subscriber, it always have ALL the subscriber.

Seems excessively complex.  Just have your main program write its message
to the file or shared memory segment and signal all the subscribed
processes.  They can then read the message and decide what, if anything, to
do.  The message should contain all the information any process could
possibly need.

1) Main program starts up, opens socket, opens message file/creates shared
memory segment, puts "default" message there (including, perhaps, the
socket it is listening on).

2) Auxillary process starts up, reads message, configures itself
accordingly, writes PID to socket.

4) Main program makes a change, writes message describing it to file/shared
memory, signals all subscribed processes.

5) Subscribed process receives signal, reads message, reacts appropriately.

Here is what I want to do:

- While my app is running it makes some changes to the configuration,
for example, creates or deletes a file.
- Other applications that depend on working on my application want to
know as soon as my app have done that.
- The usual way for them to know it is by polling but these are not
the only changes I will do. In next version I may want to include
creating/deleting users therefore I want to keep it as generic as
possible.
- There is another way for other apps to know this is by getting
system wide events but it would be difficult for them to find out who
exactly did this.
- Therefore, I was thinking about sending (broadcasting) events to all
the subscribers.
- Another way to deal with this is to actually broadcast the event but
I do not know how to broadcast the event to all applications along
with data in Linux as well.
- In addition to this, there might be a time when my app will not be
allowed to (actually) broadcast the events to ALL the apps in the
system.

Because of all this, I was thinking of implementing a simple event
reporting mechanism based on subscribers. One way I thought of doing
this by finding out whether I have parallel method in Linux to that of
Windows. Since COM is out, the other way I thought of doing this was
using shared libraries/data.

I imagine this makes it clearer.

Thanks in advance,
-Neel.

Neel,
D-Bus is the traditional way to do what you're
requesting

Hi Jens,

Here is what I want to do:

- While my app is running it makes some changes to the configuration,
for example, creates or deletes a file.
- Other applications that depend on working on my application want to
know as soon as my app have done that.

Because of all this, I was thinking of implementing a simple event
reporting mechanism based on subscribers. One way I thought of doing
this by finding out whether I have parallel method in Linux to that of
Windows. Since COM is out, the other way I thought of doing this was
using shared libraries/data.

This doesn't exist. Each process loading a shared library gets its
own, private copy of the data. What would it make sense for to have
data shared between unrelated processes?