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

[Luke Kenneth Casson Leighton]

On Thu, Jan 12, 2006 at 12:59:09PM +0100, Pawel Kot wrote:
> Hi,
> 
> On 1/12/06, Luke Kenneth Casson Leighton <address@hidden> wrote:
> > if anyone's interested, i've started an experiment to create a gnokii
> > qt app, to be compiled up initially on x86, then primarily targetted
> > at qt/embedded.
> 
> That's a good news.

 :)

> > can anyone tell me: do i stand a decent chance of being able to
> > develop _independent_ programs that don't clash - such as one
> > app that does SMS, another that does phone (only), another that
> > does contact / address-book?
> 
> In short: no.

 ah, oh well :)

> 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.

 i don't know how practical that would be.

> But
> that some logic that needs to be put in each application. And you can
> have some timeouts, starving etc.

 right now i'd not be particularly worried about that :)


> 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.

 ... but please ignore me, what do _i_ know.

> So this daemon
> exclusively communicates over libgnokii with the phone and every other
> app communicates over DBUS with this daemon. I already started some
> implementation using DCOP (as it seemed a bit easier than DBUS and had
> better support with Qt). 

 _great_.

 does qt/embedded support dcop, do you know?

 if not, i'd be more than happy to start hacking, probably by splitting
 out which subsets of AT commands can be "expected" on a connection.

 i.e. you'd register which AT commands you'd be interested to receive -
 even if the AT responses are duplicated onto multiple sockets (!)


> It's a bit ugly but I can share the code.

 that'd be cool.

> 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.

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

 l.