gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pavel Machek
Subject: Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/
Date: Sun, 15 Jan 2006 18:18:38 +0100
User-agent: Mutt/1.5.9i

On Čt 12-01-06 18:38:59, Pawel Kot wrote:
> 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.

I'm not sure that works. AT commands have _some_ state. You can choose
numeric vs. text error codes, IIRC. Mixing with simple semaphore is
going to break when someone changes parameters in a way other do not
expect.

It would be better to have some kind of multiplexing daemon.
                                                                Pavel
-- 
Thanks, Sharp!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]