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 Tony,
On 03/04/2014 06:01 PM, Tony Espy wrote:
The current bitshift logic in idmap incorrectly uses
the literal 1 for the value to shift in idmap_alloc(),
idmap_take(), and idmap_alloc_next(). This causes the
resulting value to be an int instead of a long, which
results in the wrong bit
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
On 03/05/2014 09:52 AM, Denis Kenzior wrote:
Hi Tony,
On 03/04/2014 06:01 PM, Tony Espy wrote:
The current bitshift logic in idmap incorrectly uses
the literal 1 for the value to shift in idmap_alloc(),
idmap_take(), and idmap_alloc_next(). This causes the
resulting value to be an int instead
Hi Tony,
Denis -
One of my co-workers recently sent a couple of patches that add Python3
support to the ofono test scripts, however he's not currently subscribed
to the mailing list so they emails appear to be in limbo...
Can someone clear these as a list moderator, or should I go ahead and
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
18 matches
Mail list logo