Re: [ANNOUNCE] ModemManager (for GSM and CDMA)

["Tambet Ingo" <tambet gmail com>]

It looks like I did terrible job explaining _why_ I wrote
ModemManager. Let me try again.

Where were we before ModemManager.
The current state in NetworkManager 0.7 is that we have the absolute
minimum support for modems to claim that we support modems. There are
a couple of advanced solution out there (mobile-manager, vmc, umtsmon)
that do much better job and have many more features. Multiple people
contacted us asking if we could integrate their solution, each with
different API.

How to solve that?
Given that the existing mobile applications were written in other
languages than C, it became clear we need an out of process design for
modems. So DBus was chosen. The next obstacle is that each existing
solution has it's own API. The solution I chose for this is to define
a common API that NetworkManager uses and any project that wants to be
integrated, can implement two simple interfaces. I felt it was a
better choice than using any of the existing APIs to not make anyone
feel left out.

Why did I write ModemManager?
I'm no a genius and can't define API without trying to use it.
Therefore, I needed something to test on. ModemManager is very little
apart from the newly defined DBus interface plus the modem handling
code from NetworkManager. So it's not like I've made huge investments
trying to reimplement a wheel (or existing projects).

Where are we now?
I wrote the code for NetworkManager to support out of processes modem
handling API. It's in 'ModemManager' branch in the NetworkManager's
SVN tree. We have a clear answer to any project that wants to
integrate with NetworkManager.

Do I keep working on ModemManager?
Yes. As long as existing solution can be used with NetworkManager, I
feel like I've solved the main goal. If my pet project doesn't
succeed, there's no great loss. If it does, it gives me (and possibly
others) more choice. If there are two backends, one written in python
and one in C and both do the job for me, I'd choose the C one. Other
people, depending on their specific hardware, beliefs or what not,
might choose the other.

Does it make sense?
Tambet

On Thu, Jul 31, 2008 at 6:10 PM, Tambet Ingo <tambet gmail com> wrote:
> Announcing ModemManager.
> It's a standalone DBus system service to provide a common API to
> communicate with broadband modems. It is derived from the modem
> handling code from NetworkManager and in addition to DBus API, it adds
> more operations (scanning, signal quality, changing network mode,
> band, ...). It is easy to extend by having a plugin system to provide
> "drivers" for non standard operations. There is currently one plugin
> implemented for Huawei cards. It's fully functional and can be used as
> an example to write plugins for other cards (hint! hint!).
>
> Some Q&A
>
> Q: Where can I get it?
> A: git clone git://gitorious.org/modemmanager/mainline.git modemmanager
>
> Q: What does it have to do with NetworkManager?
> A: NetworkManager will use ModemManager instead of current basic code
> in the future.
>
> Q: Can I see it in action?
> A: Yes! I've ported NM to use it already, but haven't exposed any of
> the new functionality in the UI. The fully working branch can be
> downloaded from the NetworkManager SVN branch:
>
> svn co svn+ssh://$USERNAME svn gnome org/svn/NetworkManager/branches/modem-manager
> NetworkManager-mm
>
> [or using anonymous svn]
> svn co http://svn.gnome.org/svn/NetworkManage/branches/modem-manager
> NetworkManager-mm
>
> Q: Why?
> A: There have been some requests to integrate some existing mobile
> programs with NM (vodafone, telefonica) and it's never been easier:
> All that needs to happen is to implement the same public DBus API and
> NM will use that instead.
> A2: The current modem handling code in NM is very basic, and
> supporting non standard operations and cards is pretty much impossible
> without total reorganization. Well, ModemManager is the
> reorganization.
>
> Q: You lied, it doesn't support signal monitoring while connected!
> A: No, it just means it's a non standard feature and needs a card
> specific plugin which isn't written for your card yet.
>
> Q: Is there any documentation available for it?
> A: Yes, pass a --with-docs argument to the configure and it'll create
> docs/spec.html which is the DBus API reference. There's also some
> information in the README file.
>
> Q: Can I write a plugin for my own card?
> A: Yes! Take a look at plugins/ directory to see the Huawei plugin, it
> should be pretty easy to write new ones based on that.
>
> Q: I think I've found a bug.
> A: Great! let me (tambet /at/ gmail.com for now) know. Extra points if
> you can provide a patch!
>
> Q: You API sucks!
> A: If there's something you'd like to change, either to add new
> methods or to modify the existing ones, let me know, it's not set in
> the stone.
>
> Tambet
>