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

[Luke Kenneth Casson Leighton]

On Thu, Jan 12, 2006 at 06:38:59PM +0100, 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). 

 oh _right_ - oh.  i get it.

 i like that.... ahhhh.... no.

 can't do it.  well, i _say_ can't do it...

 it's a long story, but on the himalaya, the GSM serial port needs
 "initialisation":

        http://wiki.xda-developers.com/index.php?pagename=HimalayaGSM

 at the moment, i'm doing this initialisation _every_ time someone
 does a connection to /dev/ttyS2.

 i _could_ move it to the module load...

 then it would be possible.


> This would add some delays for GUI of course.

 *shrug* :)

 ... the only time where that really matters is on an incoming phone
 call.

 you really haven't got long these days, what with the damn stupid
 things like ring-for-five-seconds-and-then-it-goes-to-voicemail,
 to answer the phone.

 heck, i've had my mobile ring _twice_ before it's gone to xxxxing
 voicemail because it took so long for the GSM network to correctly
 locate my phone.


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

 it should never have _been_ developed!  the people who scoped it out,
 initially, should have read the dce/rpc spec, gone "dang, this does
 exactly what we need, and then some, and wow, it's even a free software
 compatible license, where do we sign up?"

> >  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 :-)
 
 he he :)

> > > 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 :-)

 yeh.

 the secondary goals are messaging and contacts, however the thing that
 will get me a good warm fuzzy feeling (the amateur's version of
 success, i call it) is that first phone call.

 call that milestone 1, if you will :)

> >  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 :-)

 well, where i find that hack-it-till-it-squeaks conflicts with 
 "i can't do X because i did a really bad hacking job" then that's
 the point at which i do a refactoring and a tidyup.

 
 
-- 
--
<a href="http://lkcl.net";>http://lkcl.net</a>
--