freesmartphone.org dbus error specifications

Michael 'Mickey' Lauer mickey at vanille-media.de
Mon May 12 14:35:04 CEST 2008


Hi guys,

during the past days I put some thought into the biggest missing
thing in our API specs, which is the error specification.

DBus itself does hardly give any guidelines for error specifications --
all they really say is:
 D-Bus remote exceptions have both a textual "name" and a "message".

This gives a lot of freedom to the designer, which is why we need
to come up with a sane solution right from the start. I inspected
a couple of dbus APIs and here's my proposal:

* All dbus remote exceptions from the freesmartphone project use
the following 'name' structure:

org.freesmartphone.<API>.[Interface].<Error>

* The 'message' structure gives clear-text details about the actual
error, but is as small and concise as possible.

Remarks:

0.) We do not need to encode 'Error', neither as prefix, nor suffix, nor 
infix.
This would be redundant.

1.) We use a nested namespace rather than a flat one, this enables
fast prefix-matching, so a client might only look for the errors relevant
to it.

2.) [Interface] is optional, there might be small APIs (e.g.
org.freesmartphone.Usage or org.freesmartphone.Event)
where we do not have an interface category.

3.) <Error> does not need to be unique, e.g. you could have
org.freesmartphone.GSM.Device.NotPresent (which means the actual
modem is not present) and 
org.freesmartphone.GSM.SIM.NotPresent (which means the actual SIM
card is not present). In fact, we try to reuse terms here
to keep the taxonomy managable and have a clear semantics.

Exceptions vary, some are very generic, some are specific to
an interface, or even a method. With regards to OTAPI (our
biggest API right now), I propose the following names and
meanings for the four interfaces that I consider (almost) v1.0:

========================================
org.freesmartphone.GSM.Device
========================================
org.freesmartphone.GSM.Device.NotPresent: the (modem) device is not present
org.freesmartphone.GSM.Device.Timeout: the (modem) device did not answer 
within the expected time
org.freesmartphone.GSM.Device.Failed: the (modem) device did return an 
unspecific error

========================================
org.freesmartphone.GSM.SIM
========================================
org.freesmartphone.GSM.SIM.NotPresent: the SIM card is not present
org.freesmartphone.GSM.SIM.Unauthorized: the operation is not authorized (i.e. 
PIN required)
org.freesmartphone.GSM.SIM.NotFound: the requested entity on the SIM card 
could not be found (i.e. subscriber number, phonebook or message entry)
org.freesmartphone.GSM.SIM.MemoryFull: the requested entity could not be 
stored on the SIM card

========================================
org.freesmartphone.GSM.Network
========================================
org.freesmartphone.GSM.Network.NotPresent: there's no operator present
org.freesmartphone.GSM.Network.Unauthorized: the operation is not authorized 
(i.e. register to a specific provider)
org.freesmartphone.GSM.Network.NotFound: the requested entity (i.e. operator 
or country code) could not be found

========================================
org.freesmartphone.GSM.Call
========================================
org.freesmartphone.GSM.Call.NotFound: the requested entity (call index) could 
not be found
[for sure i'm missing some here, but i need to implement more of that API to 
understand which one ;)]

Does that make sense to you? What did I miss, what is superflous?
Depending on your comments, I would start adding these errors to
the XML specifications over the next days.

Cheers,

Mickey.
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de



More information about the smartphones-standards mailing list