[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/
From: |
Luke Kenneth Casson Leighton |
Subject: |
Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/ |
Date: |
Thu, 12 Jan 2006 23:51:23 +0000 |
User-agent: |
Mutt/1.5.5.1+cvs20040105i |
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>
--
- http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Luke Kenneth Casson Leighton, 2006/01/11
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pawel Kot, 2006/01/12
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pavel Machek, 2006/01/15
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pawel Kot, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pavel Machek, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Luke Kenneth Casson Leighton, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pavel Machek, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Luke Kenneth Casson Leighton, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pavel Machek, 2006/01/16
- Re: http://cvs.sourceforge.net/viewcvs.py/xanadux/qomunicator/, Pawel Kot, 2006/01/16