Bug 24905

Some comments on the Maemo interfaces with a view to generic applicability:

Connection.Interface.Emergency -- rename to EmergencyContacts for extra disambiguation and to reflect the purpose better?

The type Emergency_Service: Are all fields necessary? Is exposure of URNs appropriate with other protocols in Telepathy (which operates with opaque "string IDs" elsewhere)? Are the values of the alias list meant to be other URNs or human-readable strings? If the latter, is it too much information, compared to use of aliases elsewhere in Telepathy?

The property Channel.Interface.Emergency.InitialEmergencyService should be recommended to be made requestable, this being the recommended way to request an emergency call. Then one could have a separate connection (and even a separate connection manager) for emergency calls, clearly designated as such through requestable channel classes and contact capabilities.

The contacts retrieved from Connection.Interface.Emergency could provide the property discussed above in their capabilities.

Documentation for Channel.Interface.Emergency.EmergencyServiceChanged leaves it unclear when the signal is initially emitted as a "tag" signal for emergency calls, as the documentation elsewhere suggests. Should it be treated as "the moment when it becomes clear that the call is directed to a particular emergency service"? Is it a use case relevant for telephony?

(In reply to comment #1)
> Some comments on the Maemo interfaces with a view to generic applicability:
> 
> Connection.Interface.Emergency -- rename to EmergencyContacts for extra
> disambiguation and to reflect the purpose better?
> 

I would suggest something even more generic.  While the Emergency stuff is what we care about, there are other service URNs that GSM and SIP may use.  I'd suggest ServiceCall or ServiceAP (ie, Public Service Answering Point).  The idea being that you're connected to some form of service, which has some defined categories (see below).


> The type Emergency_Service: Are all fields necessary? Is exposure of URNs
> appropriate with other protocols in Telepathy (which operates with opaque
> "string IDs" elsewhere)? Are the values of the alias list meant to be other
> URNs or human-readable strings? If the latter, is it too much information,
> compared to use of aliases elsewhere in Telepathy?


Agreed on the string ID bit.  The string IDs can be "urn:service:sos", rather than specifying that it must be a URN.  Giving a service URN as an example in the spec would probably be a good idea.

I'd also suggest an enum w/ a type (that can be extended in the future) w/ each stringID.  The first type is pretty obvious: Service_Emergency.  Rfc5031 defines urn:service:counseling* as well, so we could have Service_Counseling and Service_Other, with the enum being added to in the future as more services are added.



> 
> The property Channel.Interface.Emergency.InitialEmergencyService should be
> recommended to be made requestable, this being the recommended way to request
> an emergency call. Then one could have a separate connection (and even a
> separate connection manager) for emergency calls, clearly designated as such
> through requestable channel classes and contact capabilities.
> 
> The contacts retrieved from Connection.Interface.Emergency could provide the
> property discussed above in their capabilities.
> 
> Documentation for Channel.Interface.Emergency.EmergencyServiceChanged leaves it
> unclear when the signal is initially emitted as a "tag" signal for emergency
> calls, as the documentation elsewhere suggests. Should it be treated as "the
> moment when it becomes clear that the call is directed to a particular
> emergency service"? Is it a use case relevant for telephony?
> 

Note that this sort of thing has been suggested for other protocols besides telephony; for example, SMS and IM via http://iptcomm.org/iptcomm2009papers/1569204635.pdf .

It probably makes sense to add this as a channel interface that doesn't depend upon StreamedMedia or Call..

I've pushed a first draft for this - 

http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/srvp

I'm unsure about the Aliases bit in the Connection iface..

(In reply to comment #3)
> I've pushed a first draft for this - 
> 
> http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/srvp
> 
> I'm unsure about the Aliases bit in the Connection iface..
> 


I just pushed a fix to the branch and addressed some additional points.

drive-by feedback:

• maybe GetCurrentService() → s, u should just be a pair of d-bus properties, ServicePoint and ServicePointType?
• the point of the enum is so that your UI can tell it's an emergency call without having to parse the string, but if you want you can find out that in particular it's an emergency call to the fire brigade, right? if so, shouldn't there also be an InitialServicePointType property?

(In reply to comment #5)
> drive-by feedback:
> 
> • maybe GetCurrentService() → s, u should just be a pair of d-bus
> properties, ServicePoint and ServicePointType?

Hm, possibly.  I'm tempted to group them together as a struct; would that be acceptable?

> • the point of the enum is so that your UI can tell it's an emergency call
> without having to parse the string, but if you want you can find out that in
> particular it's an emergency call to the fire brigade, right? if so, shouldn't
> there also be an InitialServicePointType property?
> 

Good point, just added it.  Thanks.

Should KnownServicePoints() on the connection interface be renamed to GetKnownServicePoints()?

(In reply to comment #7)
> Should KnownServicePoints() on the connection interface be renamed to
> GetKnownServicePoints()?

Good point. This actually got me thinking whether it shoulod be a property instead of a method. This seems more natural to me (bikeshedding time).

In any case, as far as I can see, there are no other open issues to address, so if the Cabal is happy, we could proceed on merging it for the next spec release.

Apparently these comments from http://lists.freedesktop.org/archives/telepathy/2010-April/004452.html didn't actually make it over here.

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
• For documentation purposes there should be a TpSimpleType for URN strings, so we can use that as the type for ServicePoint.
• Service_Point_Type 0 should be None instead of Unknown for a dummy value

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 ?
• Simon would like to see a example of Service_Point_Struct in the spec.
• Also Service_Point_Struct should be renamed to Service_Point_Info

(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

+    <property name="CurrentServicePoint" tp:name-for-bindings="Current_Service_Point"
+      type="(us)" tp:type="Service_Point" access="read">
       <tp:docstring>
+        Service point this channel is connected to. If channel is n
         Get the current service point that a channel is connected to.
       </tp:docstring>

I don't think you finished editing this docstring. ☺

This otherwise looks good to me.

I've had another look at this and made some editorial changes. With those changes, I think it's ready to undraft.

Gitweb:
http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/servicepoint
HTML:
http://people.freedesktop.org/~smcv/telepathy-spec-servicepoint/spec/

> > • 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).

I've removed this simple-type, since either its name or its documentation is incorrect (it's documented as urn:service:*, but its name ought to be for urn:*). I don't think having a simple-type adds anything to the documentation here, because it's only referenced in one place, and that's "optional" - I moved the RFC reference to appear in the one place where the simple-type was referenced, which I think is equally good.

12:58 < wjt> smcv: lassi says anonymity and servicepoint look fine for 
             undrafting from Ring's POV

Looks fine to me!

Fixed in git, will be considered stable in 0.19.7.