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

[Pavel Machek]

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

when you can parse 

ATDT1234;

as well, and it has added benefit of not having reinvent another
protocol. But it probably makes sense to stop AT compatibility at
places like calendar/contact/file manipulation, where there's no AT
standard or the standard is incredibly ugly.
                                                                Pavel
-- 
Thanks, Sharp!