VL: Service namespace
Wally Ritchie
wally.ritchie at gmail.com
Fri Dec 7 04:45:58 CET 2007
On Dec 6, 2007 7:12 PM, Katila Matti <matti.katila at ixonos.com> wrote:
>
> On Dec 6. 2007 18:35 Wally Ritchie wrote:
> > On Dec 6, 2007 8:31 AM, Michael 'Mickey' Lauer wrote:
> >> Katila wrote:
[snip]
>
> While I like short names I think mtl isn't widely known term. For
> example neither google or V.E.R.A knows it:
> http://www.delorie.com/gnu/docs/vera/vera_14.html
> http://www.google.com/search?hl=en&c2coff=1&q=%22Mobile+Termination+Layer%22&btnG=Search
> Your search - "Mobile Termination Layer" - did not match any documents.
>
Mobile Termination Layer is a new term. You will find lots under
Mobile Termination because
that's the GSM name for the architectural entity between the Baseband
and the Application
Processor (MMI). This Layer is intended to be interface between the
"Phone Part" of the
smartphone and the User Interface in whatever form.
> I happen to like the symbolism that freesmartphone.org derives from
> freedesktop.org. For short name freedesktop.org is sometimes refered
> with f-d-o. Thus, we could use f-s-o for short. Anyway, prefix is
> something that is read once and newer afterwards.
>
hmmm - you might think a bit differently after you begin testing with
things like:
$ dbus-send --system --print-reply --dest=org.freesmartphone
org.freesmartphone.MobileTelephony.GetSomeEsotericPieceOfInformation
string:"123456" string:"whatever"
>
> >> org.freesmartphone.Telephony as prefix.
> >
> > Perhaps I'm being too limiting but it seems to me we are clearly in
> > the MOBILE space, i.e. mobile telephony. The term MS (Mobile Station)
> > has been used for decades (PLMN). Especially because this is a global
> > effort, I think we need to use the most applicable terms from
> > international standards unless there is a good reason not to.
>
> If we are going to use terms used on the field we should use all terms
> accordingly. And I think that would be wrong option. If that way is
> chosen I need to step aside from the discussion since I have not
> enough experties from wireless communications. This would limit
> developers who are familiar with normal phone - even the API will be
> all the things used on a normal phone. I'm not saying this because of
> I like to join the discussion but I'm scare of the hobbyist who want
> to use the API but find it cryptic.
>
I'm not sure what you saying here. You think using the proper industry terms
would be the wrong way to go? Instead of just learning the terms, you propose
making up something new. I do agree that things should be made as simple
as possible - but no simpler. I also agree that there should be simple ways to
do simple things. But there is a lot of complexity underneath. The challenge is
to handle the complexity in a way that makes it manageable for the programmer
and easy for the ultimate user.
Operation of GSM/UMTS handsets can be complex. A lot of things can go on at
the same time and have to be presented to upper layers in a rational
and sane manner.
For example, consider you are on a call, and another call comes in, and as SMS
message, and a Intercomm call over BT, and a SIP call over WiFi. These are real
possible scenarios. Even with GSM alone there are two possible calls. These are
the kinds of things that have to presented from the MT layer to the UI
layer in such
a way that things can be handled sanely.
It is going to take some time to get this right but we want to be able
to support the
widest range of scenarios, GSM/UMTS, dual radios, SIP over WIFI, BT intercoms,
multiple data connections, etc.
Please don't get discouraged just because you don't already have all
the expertise.
Few do. It's a mountain of stuff. But it's not insurmountable. The
parts of this that
we are working on here are not black magic. It's all well documented.
Just dig in a
bit and it will start to make sense as things get pulled together. It
won't be too long before
some easy and simple parts can be pelled off to get things rolling.
Cheers
>
[snip]
More information about the Smartphones-standards
mailing list