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: Fri, 20 Jan 2006 22:46:59 +0100
User-agent: Mutt/1.5.9i

On Pá 20-01-06 21:03:24, Luke Kenneth Casson Leighton wrote:
> On Fri, Jan 20, 2006 at 06:38:50PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > Daemon that presents 5 virtual telephones talking to one real
> > > > > > telephone, or something like that. Similar to gpsd.
> > > > >
> > > > > Need to look at gpsd. But I think virtual telephone may be a bit too
> > > > > much. I like to look at it as on the message bus supporting
> > > > > synchronous and asynchronous communication. I can't see any additional
> > > > > value from virtual phone abstraction.
> > > >
> > > >  the principle behind gpsd is that you issue _simple_ commands
> > > >  of one character in length, and the responses come back "preparsed".
> > > >
> > > >  so gpsd takes care of parsing the NMEA data for you, and if you happen
> > > >  to know which one-character commands to type, then you can just telnet
> > > >  to gpsd and get a rough idea of what's going on.
> > > 
> > > But that's just proxy. Just a bit more intelligent. No need for any
> > > virtual phones (if we have the same understanding of the virtual
> > > phone). Just the API for giving commands and sending responses. State
> > > and other internals are handled internally by the proxy. And I think
> > > AT command interface will not be suitable: you won't be able to do too
> > > many things (starting with file operations).
> > 
> > Well, file operations are not nice to do over AT, and neither is
> > calendar manipulation. Not sure about sim-card contact manipulation.
> > 
> > I still believe it is reasonable to do AT commands where they make
> > sense, and the rest with custom protocol. In my eyes it is stupid to
> > do voice call with
> > 
> > D1234
>  
>  this one requires:
> 
>  switch (input[0])
>  case 'D':
>       gn_dial_phone(input+1);
> 
>       break;
> 
> > when you can parse 
> > 
> > ATDT1234;
>  
>  this one requires:
> 
>  if (strncmp(input, "ATDT", 4) == 0)
>       gn_dial_phone(input + 5)
>  else if ....
> 
>  i know which one i prefer :)

Yes, I know which one you prefer. OTOH on the other side, it is

if (we_are_using_proxy)
        sprintf(dialString, "D%s", phoneNum);
else
        sprintf(dialString, "ATD%s;", phoneNum);

vs.

sprintf(dialString, "ATD%s;", phoneNum);

and so on, ifs near the error handling etc. And then you run out of
letters. There are many applications, yet there's only one proxy. I
think slightly more complex parsing in proxy is worth simplyfying the
apps.

> > as well, and it has added benefit of not having reinvent another
> > protocol. 
> 
>  if it was a complex system, with hundreds of commands, complex
>  interaction, i'd agree with you.
> 
>  ... but this is _so_ trivial ...

It is going to evolve into complex system... Phones are quite complex.

                                                        Pavel
-- 
Thanks, Sharp!




reply via email to

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