On 03/05/2014 09:41 PM, Marcel Holtmann wrote:
Hi Tony,
We've been working on MMS support for Ubuntu Touch recently and have run into a
couple of stumbling blocks, so I have a few questions about the current MMS
logic in oFono ( we're still 1.12 based ), and in particular the
Hi Tony,
Actually though, I do have one question about the API being frozen. Are
there any plans to remove the OFONO_API_SUBJECT_TO_CHANGE pre-processor
logic in plugins.h?
Nope. The D-Bus API is frozen and we take that seriously. The internal
API will likely never be.
We value the
On 03/06/2014 12:54 AM, Denis Kenzior wrote:
Hi Tony,
3. For the shared case, the driver context code could be optimized to
recognize that a context being activated has the same apn as an already
activated context and just mark the new context activated, borrowing the
'Settings' from the
3. No way to associate additional APN properties with a gprs_context.
apns-conf.xml has many additional APN attributes which don't map
directly to gprs_context properties ( eg. authtype, mvno_type, ... ).
If you have usecases in mind for some of these properties, feel free
to suggest
Hi Slava,
On 03/05/2014 03:39 AM, Slava Monich wrote:
3. No way to associate additional APN properties with a gprs_context.
apns-conf.xml has many additional APN attributes which don't map
directly to gprs_context properties ( eg. authtype, mvno_type, ... ).
If you have usecases in mind
Hi Denis,
What do you think about extending org.ofono.ConnectionContext API with
Add/RemoveProperty calls and PropertyAdded/Removed signals to allow
platform/application specific properties of type string? Use cases
include marking connections as preferred/default or assigning priorities
to
Hi Slava,
A couple of examples.
Suppose, we have a UI that allows the user to switch between Automatic
and Custom MMS or GPRS settings. One of the ways to implement that
would be to create a new context marked as manual and allow the user
to edit it. The old context remains but it's marked as
Hi Tony,
We've been working on MMS support for Ubuntu Touch recently and have run into
a couple of stumbling blocks, so I have a few questions about the current MMS
logic in oFono ( we're still 1.12 based ), and in particular the
provisioning/management of gprs-contexts.
As part of this
Hi Slava,
What do you think about extending org.ofono.ConnectionContext API with
Add/RemoveProperty calls and PropertyAdded/Removed signals to allow
platform/application specific properties of type string? Use cases
include marking connections as preferred/default or assigning priorities
to
Hi Marcel,
I am not even sure what’s your goal here? Are just trying to plain copy the
horrible crap that Android puts in front of their users? You do realize that
their list of APNs just purely exists since they never figured out on how to do
the automatic provisioning properly and user
Hi Slava,
not my job as a middleware developer to design the UI. But in the end
when it's decided which settings should be per-SIM and which are global,
I see ofono which I'm already using and which implements persistent
per-SIM storage, property change notifications and other niceties and
Hi Denis,
Hi Slava,
not my job as a middleware developer to design the UI. But in the end
when it's decided which settings should be per-SIM and which are global,
I see ofono which I'm already using and which implements persistent
per-SIM storage, property change notifications and other
On 03/05/2014 12:57 PM, Marcel Holtmann wrote:
Hi Tony,
We've been working on MMS support for Ubuntu Touch recently and have run into a
couple of stumbling blocks, so I have a few questions about the current MMS
logic in oFono ( we're still 1.12 based ), and in particular the
On 03/04/2014 10:13 PM, Denis Kenzior wrote:
Hi Tony,
Now perhaps I missed something and there is a way to represent a
combined usage APN ( maybe using TYPE_ANY? ), but I couldn't see how to
accomplish without changes to the core gprs code.
Thanks for the reply Denis.
oFono is not
On 03/05/2014 01:29 PM, Marcel Holtmann wrote:
Hi Slava,
What do you think about extending org.ofono.ConnectionContext API with
Add/RemoveProperty calls and PropertyAdded/Removed signals to allow
platform/application specific properties of type string? Use cases
include marking connections as
Hi Tony,
We've been working on MMS support for Ubuntu Touch recently and have run
into a couple of stumbling blocks, so I have a few questions about the
current MMS logic in oFono ( we're still 1.12 based ), and in particular
the provisioning/management of gprs-contexts.
As part of this
Hi Tony,
What do you think about extending org.ofono.ConnectionContext API with
Add/RemoveProperty calls and PropertyAdded/Removed signals to allow
platform/application specific properties of type string? Use cases
include marking connections as preferred/default or assigning priorities
to
Hi Tony,
3. For the shared case, the driver context code could be optimized to
recognize that a context being activated has the same apn as an already
activated context and just mark the new context activated, borrowing the
'Settings' from the first.
It might work. Generally all contexts
We've been working on MMS support for Ubuntu Touch recently and have run
into a couple of stumbling blocks, so I have a few questions about the
current MMS logic in oFono ( we're still 1.12 based ), and in particular
the provisioning/management of gprs-contexts.
As part of this work, we're
Hi Tony,
Now perhaps I missed something and there is a way to represent a
combined usage APN ( maybe using TYPE_ANY? ), but I couldn't see how to
accomplish without changes to the core gprs code.
oFono is not designed to handle combined usage APNs. If the APN for MMS
and Internet is the
20 matches
Mail list logo
