[Bug 24905] Emergency call identification

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24905

Senko Rasic <senko at senko.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #10 from Senko Rasic <senko at senko.net> 2010-04-29 06:59:56 PDT ---
(In reply to comment #9)
> o.f.t.Channel.Interface.ServicePoint:
> 
> • GetCurrentService should become two properties [or maybe a single
> struct-typed property? -ed.] instead of being a getter method

Since the (service,type) pair creeps up everywhere (InitialServicePoint,
CurrentServicePoint, ServicePointChanged), I think it's best if we made it a
struct.

> • For documentation purposes there should be a TpSimpleType
> for URN strings, so we can use that as the type for ServicePoint.

Not really, since the string content for Service is intentionally opaque. The
URN example is just an example. Various protocols might have completely
different semantics for this field.

That said, I did add URN simple type, since it improves docs a bit and can
probably be used elsewhere in the spec where we're dealing with URNs (if
anywhere).

> • Service_Point_Type 0 should be None instead of Unknown for a dummy value

Fixed.


> o.f.t.C.I.ServicePoint:
> 
> • ServiceHandle should be ServiceID, No need for it to  be handle: the UI will
> be dealing with it as an ID anyway
> • And/Or AliasList should be ServiceIDs and ServiceHandle should disappear
> completely. It wasn't clear to us what the rationale/use-case for having one
> ServiceHandle and then a list of aliases is ?

AIUI the rationale is that you can have several IDs mapping to the same
service, which would then logically be just one handle. To have that mapping,
you'd have multiple aliases in AliasList.

Since UI doesn't need ServiceHandle, there's no need to differ between
ServiceID and AliasList (assuming all the possible IDs are equal), so I've
replaced it with ServiceIDs.

> • Simon would like to see a example of Service_Point_Struct in the spec.

Added an example with GSM emergency calls.

> • Also Service_Point_Struct should be renamed to Service_Point_Info

Changed. Also, a bit of bikeshedding: if we have Service_Point and
Service_Point_Struct, is it reasonable to just stuff ServiceIDs in
Service_Point? In which case we'd have to say they're ignored in
InitialServicePoint (ie. the client doesn't need to set them).

The updated branch is available at:
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/srvp

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.