Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/

[Pawel Kot]

Hi,
> > With explanation: you could do it currently in a bit complicated way
> > that every single app is doing locking and unlocking on its own.
>
>  yes, i kinda figured something like that - orrr....
>
>  you register on a "phone" socket, and you can only send/receive
>  "phone" stuff - incoming/outgoing calls.
>
>  you register on a "SMS" socket, and you can only get a subset of the AT
>  commands that deal with SMS (including error messages).
>
>  likewise for address book stuff.

No. I thought other way. gnokii has locking mechanism. And every app
should keep the connection just when it needs it (so connect, do what
you need, disconnect). This would add some delays for GUI of course.
Similiar approach would be to have the separate app that on startup
initializes the connection, sends keepalive packets and disconnects on
exit. It would also keep a semaphone. When the semaphone is taken it
would not send keepalive. The applications would try to gain the
semaphore when needing to send something and releasing afterwards.
Again some disadvantages: some delays with GUI, possible starvation
(depending on semaphore implementation), implementation of this
connection manager. This should be possible to do but I'm not sure.

> > The better idea was already discussed here but unfortunately due ot my
> > lack of time was not implemented. It is to create some daemon
> > communicating with DBUS (preferably, but maybe with plugins with other
> > communication layers as DCOP or anything else).
>
>  as someone who understands and loves DCE/RPC, i _despise_ dbus as the
>  specifications for d-bus transport is near-identical to DCE/RPC's
>  low-level transport, and it was _such_ a friggin waste of _yet_ another
>  not-invented-here syndrome bunch of stupidity.  and money.

IMVHO it is yet another approach to the inter-everything communication
but looks promising. It is a bit depressing to see how slowly it got
developed, but it seems it's getting widely accepted (maybe not in MS
world).

>  does qt/embedded support dcop, do you know?

Not sure, but probably yes.

> > It's a bit ugly but I can share the code.
>
>  that'd be cool.

I'll try to put it tonight somewhere. But don't get scared. You've
been warned :-)

> > More important is the design though. So we wouldn't need to rewrite it
> > in short time.
> >
> > I'm willing to help but probably won't be able to code everything.
>
>  no problem - i just want to get phone calls working, first, then move
>  on from there.

And I'd like to have much more :-)

>  i do have to warn you in advance: i'm not fussy about code quality, i'm
>  fussy about "working" and "doingthejob(tm)".

That causes the problem when you need to maintain the program and add
new functionality :-)

take care,
pkot
--
Pawel Kot
http://www.gnokii.org/