gsmd/libgsm architecture

[Alan Jones]

Wally,

> gsmd then becomes a general 7.07 session handler. It accepts 7.07 streams
> over a multiplicity of sessions and responds based on the state of the
> core MT generally and the state of the particular session. It would
> also need to interface to whatever database stores the MT data not
> stored on the SIM.

I think you identify a good deficiency in the current plan, in that there does not seem to be any plans to support 07.07 commands
which terminate to the application processor instead of the GSM chipset. However, my mind takes me to a slightly different solution.
In my vision, it is highly desirable to keep all knowledge of the archaic 07.07 AT commands entirely contained in gsmd. I would
propose an architecture not so dissimilar to what you are suggesting: gsmd would have three primary interfaces: the 07.07/07.10 link
to the GSM chipset (somewhat of a "client" model), the transport independent 07.07 (and possibly 07.10) links coming in from
BT/USB/whatever (somewhat of a "server" model), and finally a DBUS link from resident applications (or possibly external apps over
IP).

In this world, there would essentially be a subsystem within gsmd which all external TE 07.07 streams terminate to. That subsystem
would essentially act as a smart proxy, acting as a TA to the external entity and somewhat of a TE from the chipset's perspective,
processing each command received. Some of them may go straight to the chipset, while others may be implemented in a more combined
mechanism as you described, for things like phonebooks and SMS. This brings me to the first reason why I think that using dbus
directly from gsmd is desirable instead of the existing proprietary or proposed 07.07 based protocols. In order for gsmd to service
these phonebook or SMS requests, it is going to need to interact with whatever entity controls that data. Presumably this is the
embedded evolution data server, who's primary (only?) interface is dbus.

As a final note on this interface, I think that implementing 07.10 for external TE is of limited utility, but should not be
precluded. I know there is at least one user-land implementation (albeit TE-side focused) out there.

In my opinion, except for debugging, there is little value in giving applications (even if there is a library to abstract it) access
to 07.07 level activities. Applications are going to be interested in much higher level events like "Make Call", "SMS Received",
etc... I would love to see a situation where the dbus API exported is high enough level that libgsm would entirely disappear.
Applications would simply receive alerts and make method calls on the gsmd dbus presence directly (maybe a little dbus framework
will be needed, but most apps should already have this). 

> Some would, I suppose, argue that AT commands are too complicated as
> an API. This is where a libgsm fits in. Any libxxx layer would
> talk to the core MT through a 7.07 stream. Different libraries could
> abstract the 7.07 session in different ways depending on the preferences
> of the particular application programmer. These libraries could have
> various bindings to whatever. gsmd, however,  would remain the stable
> base for all of them. Multiple libgsm equivalents could coexist and
> I expect that one of them would eventual dominate.

As is likely apparent above, my vision leads me to keep the application layer access library as minimal as possible, really just
providing IPC with little to no logic. In my opinion, having multiple applications possibly querying and processing
similar/identical 07.07 streams (and potentially parsing SMS TPDUs, etc...) is undesirable. 

One example of a situation where this scheme would be very slick is for SMS reception. gsmd would receive  the asynchronous 07.07
event, query out the message, and post a "New SMS" alert to its dbus subscribers containing maybe a message reference (which can be
used to retrieve the entire message from gsmd), as well as maybe some useful information like origination address and a short text
summary (or maybe just the whole message). The two key applications which I could see being interested in this would be the SMS
reader and some sort of notification applet to pop a notification to the user. Both could receive the alert and take appropriate
actions without redundantly accessing the chipset. (of course, there are other solutions to this specific issue, it is just used as
an example)
 
The final thing I feel that this brings to the system is a better sharing of state information about the GSM chipset. Instead of
everything in the system thinking it has an exclusive connection to the GSM chipset, there is an intermediary keeping track of
things. It changes the mindset a little, and might help provide more useful failure information to the user if conflicting requests
are made. You especially wouldn't want two applications simultaneously trying to establish GPRS connectivity using virtual
"independent" links to the chipset, something needs to be in charge of that. 

On that topic (but a bit off the main topic), does anybody know if the GSM chipset supports multiple simultaneous PDP contexts? If
not, then the external TE support proxy will need to be cognizant of the state of the "internal" GPRS connection status. In this
case, maybe the ability to be a NAT gateway over WiFi or Ethernet might be useful. Alternately, it would be theoretically possible
to allow the external TE to terminate its PPP link directly to the Neo, which NATs the traffic out over GPRS.


> I am toying with the idea of undertaking the writing of an alternative
> gpsd that would implement the above approach. I do not want to re-invent
> the wheel but neither do I want to use a pentagon where a wheel is
> needed.

If it helps, I too am pondering this idea. At a minimum, I have a mind to build an additional, higher-level "gsmd+" which sits at
the dbus level and implements the above described architecture on top of libgsm's passthrough mode. This interim solution might not
be so bad in the long haul either. To go back to your point about building a solid gsmd focused on providing a solid 07.07
foundation, maybe this extra separation will turn into a reasonable long term architecture. Providing essentially a higher level
dbus-based "gsmd+" for applications and external TEs to access, which interfaces with gsmd via 07.07. Possibly reducing the
"clients" that gsmd services to only the "gsmd+" process.

Thoughts?

-Alan