[RFC] Add agent API to message atom

[RFC] Add agent API to message atom

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

---
 doc/message-api.txt |   97 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/doc/message-api.txt b/doc/message-api.txt
index 693a111..ce96315 100644
--- a/doc/message-api.txt
+++ b/doc/message-api.txt
@@ -26,6 +26,66 @@ Methods		dict GetProperties()
 
 			Send the message in text to the number in to.
 
+		void RegisterTextAgent(object path, string match)
+
+			Registers an agent to receive messages.
+
+			The object path defines the path of the agent that
+			will be called when a message is ready to be
+			dispatched.  The match parameter takes an optional
+			matching rule in a restricted subset of regular
+			expression syntax.
+
+			TODO: accepted regexp syntax.  Perhaps only allow
+			simple match rules for the beginning and end of a
+			message, as well as a free text token match for the
+			entire message.
+
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.InUse
+
+		void RegisterPushAgent(object path, string id)
+
+			Registers an agent to receive push messages.
+
+			The object path defines the path of the agent that
+			will be called when a push message is ready to be
+			dispatched.  The id parameter takes an optional
+			WAP application ID that is used to match incoming
+			push messages.
+
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.InUse
+
+		void RegisterApplicationAgent(object path, uint dest, uint src)
+
+			Registers an agent to receive application messages.
+
+			The object path defines the path of the agent that
+			will be called when an application message is ready
+			to be dispatched.
+
+			The dest parameter is the destination application
+			port number, and the src parameter is the optional
+			source application port number.
+
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.InUse
+
+		void UnregisterAgent(object path)
+
+			Unregisters an agent.  If no agent is registered
+			that matches the type of an arriving message, it is
+			silently dropped.
+
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.NotFound
+					 [service].Error.NotAuthorized
+
 Signals		PropertyChanged(string name, variant value)
 
 			This signal indicates a changed value of the given
@@ -64,3 +124,40 @@ Properties	string ServiceCenterAddress
 				"ps-preferred" - Use CS if PS is unavailable
 
 			By default oFono uses "cs-preferred" setting.
+
+
+MessageAgent Hierarchy [experimental]
+===============
+
+Service		unique name
+Interface	org.ofono.MessageAgent
+Object path	freely definable
+
+Methods		void ImmediateMessage(string message, dict info)
+
+			New immediate (class 0) SMS received.  Info has Sender,
+			LocalSentTime, and SentTime information.  Sender
+			address is given in string format.  LocalSentTime and
+			SentTime are given in string form using ISO8601 format.
+
+		void IncomingMessage(string message, dict info)
+
+			New incoming text SMS received.  Info has Sender,
+			LocalSentTime, and SentTime information.
+
+		void IncomingPush(array{byte} message, dict info)
+
+			New incoming push message received.  Info has Sender,
+			LocalSentTime, SentTime, and ApplicationId information.
+
+		void IncomingApplication(array{byte} message, dict info)
+
+			New incoming application message received.  Info has
+			Sender, LocalSentTime, SentTime, DestinationPort, and
+			SourcePort information.
+
+		void Release()
+
+			Agent is being released, possibly because of oFono
+			terminating, the MessageManager interface being torn
+			down or modem powering down.
-- 
1.7.0.4

Re: [RFC] Add agent API to message atom

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 4327 bytes --]

Hi Aki,

>  doc/message-api.txt |   97 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 97 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/message-api.txt b/doc/message-api.txt
> index 693a111..ce96315 100644
> --- a/doc/message-api.txt
> +++ b/doc/message-api.txt
> @@ -26,6 +26,66 @@ Methods		dict GetProperties()
>  
>  			Send the message in text to the number in to.
>  
> +		void RegisterTextAgent(object path, string match)
> +
> +			Registers an agent to receive messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when a message is ready to be
> +			dispatched.  The match parameter takes an optional
> +			matching rule in a restricted subset of regular
> +			expression syntax.
> +
> +			TODO: accepted regexp syntax.  Perhaps only allow
> +			simple match rules for the beginning and end of a
> +			message, as well as a free text token match for the
> +			entire message.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
> +		void RegisterPushAgent(object path, string id)
> +
> +			Registers an agent to receive push messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when a push message is ready to be
> +			dispatched.  The id parameter takes an optional
> +			WAP application ID that is used to match incoming
> +			push messages.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
> +		void RegisterApplicationAgent(object path, uint dest, uint src)
> +
> +			Registers an agent to receive application messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when an application message is ready
> +			to be dispatched.
> +
> +			The dest parameter is the destination application
> +			port number, and the src parameter is the optional
> +			source application port number.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
> +		void UnregisterAgent(object path)
> +
> +			Unregisters an agent.  If no agent is registered
> +			that matches the type of an arriving message, it is
> +			silently dropped.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.NotFound
> +					 [service].Error.NotAuthorized
> +

I prefer if we can do a RegisterAgent and UnregisterAgent like we have
in the STK interface. This makes it a lot more consistent throughout the
whole oFono APIs.

This of course means that we need a bit more intelligent matching of the
handled types. In general I am against the overhead of regex for this. I
prefer glob style matching with just * and ?. That should be good
enough. If you really need regex pattern matching then then I think a
specialized oFono plugin with its own APIs is the way to go.


> +MessageAgent Hierarchy [experimental]
> +===============
> +
> +Service		unique name
> +Interface	org.ofono.MessageAgent
> +Object path	freely definable
> +
> +Methods		void ImmediateMessage(string message, dict info)
> +
> +			New immediate (class 0) SMS received.  Info has Sender,
> +			LocalSentTime, and SentTime information.  Sender
> +			address is given in string format.  LocalSentTime and
> +			SentTime are given in string form using ISO8601 format.

Should these really be delivered via an agent?

> +		void IncomingMessage(string message, dict info)
> +
> +			New incoming text SMS received.  Info has Sender,
> +			LocalSentTime, and SentTime information.
> +
> +		void IncomingPush(array{byte} message, dict info)
> +
> +			New incoming push message received.  Info has Sender,
> +			LocalSentTime, SentTime, and ApplicationId information.
> +
> +		void IncomingApplication(array{byte} message, dict info)
> +
> +			New incoming application message received.  Info has
> +			Sender, LocalSentTime, SentTime, DestinationPort, and
> +			SourcePort information.

Why the difference between Push and Application. The dict could be
easily used here to differentiate.

Regards

Marcel

Re: [RFC] Add agent API to message atom

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 4161 bytes --]

Hi,

2010/8/31 Marcel Holtmann <marcel@holtmann.org>:
>> +             void RegisterApplicationAgent(object path, uint dest, uint src)
>> +
>> +                     Registers an agent to receive application messages.
>> +
>> +                     The object path defines the path of the agent that
>> +                     will be called when an application message is ready
>> +                     to be dispatched.
>> +
>> +                     The dest parameter is the destination application
>> +                     port number, and the src parameter is the optional
>> +                     source application port number.
>> +
>> +                     Possible Errors: [service].Error.InvalidArguments
>> +                                      [service].Error.InvalidFormat
>> +                                      [service].Error.InUse
>> +
>> +             void UnregisterAgent(object path)
>> +
>> +                     Unregisters an agent.  If no agent is registered
>> +                     that matches the type of an arriving message, it is
>> +                     silently dropped.
>> +
>> +                     Possible Errors: [service].Error.InvalidArguments
>> +                                      [service].Error.InvalidFormat
>> +                                      [service].Error.NotFound
>> +                                      [service].Error.NotAuthorized
>> +
>
> I prefer if we can do a RegisterAgent and UnregisterAgent like we have
> in the STK interface. This makes it a lot more consistent throughout the
> whole oFono APIs.

Ok.

> This of course means that we need a bit more intelligent matching of the
> handled types. In general I am against the overhead of regex for this. I
> prefer glob style matching with just * and ?. That should be good
> enough. If you really need regex pattern matching then then I think a
> specialized oFono plugin with its own APIs is the way to go.

This was basically what I was thinking, too, with the addition of ^
and $ for matching at the end or beginning of a message.

>> +Methods              void ImmediateMessage(string message, dict info)
>> +
>> +                     New immediate (class 0) SMS received.  Info has Sender,
>> +                     LocalSentTime, and SentTime information.  Sender
>> +                     address is given in string format.  LocalSentTime and
>> +                     SentTime are given in string form using ISO8601 format.
>
> Should these really be delivered via an agent?

Why not?

>> +             void IncomingMessage(string message, dict info)
>> +
>> +                     New incoming text SMS received.  Info has Sender,
>> +                     LocalSentTime, and SentTime information.
>> +
>> +             void IncomingPush(array{byte} message, dict info)
>> +
>> +                     New incoming push message received.  Info has Sender,
>> +                     LocalSentTime, SentTime, and ApplicationId information.
>> +
>> +             void IncomingApplication(array{byte} message, dict info)
>> +
>> +                     New incoming application message received.  Info has
>> +                     Sender, LocalSentTime, SentTime, DestinationPort, and
>> +                     SourcePort information.
>
> Why the difference between Push and Application. The dict could be
> easily used here to differentiate.

True. And in fact we discussed this in IRC with Denis a bit and
decided that separating WAP push makes little sense overall. If the
agent needs to decode the WSP anyway, we're not providing much value
add in oFono just decoding the X-Wap-Application-Id header field. So
the agent might as well just use the application ports to register.

Cheers,
Aki

Re: [RFC] Add agent API to message atom

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]

Hi Aki,

> >> +             void RegisterApplicationAgent(object path, uint dest, uint src)
> >> +
> >> +                     Registers an agent to receive application messages.
> >> +
> >> +                     The object path defines the path of the agent that
> >> +                     will be called when an application message is ready
> >> +                     to be dispatched.
> >> +
> >> +                     The dest parameter is the destination application
> >> +                     port number, and the src parameter is the optional
> >> +                     source application port number.
> >> +
> >> +                     Possible Errors: [service].Error.InvalidArguments
> >> +                                      [service].Error.InvalidFormat
> >> +                                      [service].Error.InUse
> >> +
> >> +             void UnregisterAgent(object path)
> >> +
> >> +                     Unregisters an agent.  If no agent is registered
> >> +                     that matches the type of an arriving message, it is
> >> +                     silently dropped.
> >> +
> >> +                     Possible Errors: [service].Error.InvalidArguments
> >> +                                      [service].Error.InvalidFormat
> >> +                                      [service].Error.NotFound
> >> +                                      [service].Error.NotAuthorized
> >> +
> >
> > I prefer if we can do a RegisterAgent and UnregisterAgent like we have
> > in the STK interface. This makes it a lot more consistent throughout the
> > whole oFono APIs.
> 
> Ok.
> 
> > This of course means that we need a bit more intelligent matching of the
> > handled types. In general I am against the overhead of regex for this. I
> > prefer glob style matching with just * and ?. That should be good
> > enough. If you really need regex pattern matching then then I think a
> > specialized oFono plugin with its own APIs is the way to go.
> 
> This was basically what I was thinking, too, with the addition of ^
> and $ for matching at the end or beginning of a message.

within GLib we have glob pattern matching functions, but nothing that
additionally takes ^ and $. Why do you think this would be useful and
needed? How many message agents to you expect to be running that are not
using port numbers? Do you have some examples messages in mind?

> >> +Methods              void ImmediateMessage(string message, dict info)
> >> +
> >> +                     New immediate (class 0) SMS received.  Info has Sender,
> >> +                     LocalSentTime, and SentTime information.  Sender
> >> +                     address is given in string format.  LocalSentTime and
> >> +                     SentTime are given in string form using ISO8601 format.
> >
> > Should these really be delivered via an agent?
> 
> Why not?

These class 0 message are special and I think the home screen applet can
just use the current D-Bus signal to deal with them. I don't think that
we need special handling for them.

> >> +             void IncomingMessage(string message, dict info)
> >> +
> >> +                     New incoming text SMS received.  Info has Sender,
> >> +                     LocalSentTime, and SentTime information.
> >> +
> >> +             void IncomingPush(array{byte} message, dict info)
> >> +
> >> +                     New incoming push message received.  Info has Sender,
> >> +                     LocalSentTime, SentTime, and ApplicationId information.
> >> +
> >> +             void IncomingApplication(array{byte} message, dict info)
> >> +
> >> +                     New incoming application message received.  Info has
> >> +                     Sender, LocalSentTime, SentTime, DestinationPort, and
> >> +                     SourcePort information.
> >
> > Why the difference between Push and Application. The dict could be
> > easily used here to differentiate.
> 
> True. And in fact we discussed this in IRC with Denis a bit and
> decided that separating WAP push makes little sense overall. If the
> agent needs to decode the WSP anyway, we're not providing much value
> add in oFono just decoding the X-Wap-Application-Id header field. So
> the agent might as well just use the application ports to register.

Personally I like the idea of doing the whole WSP decoding inside oFono,
but if we have WAP Push over IP transport and the WAP Push daemon has to
do the decoding again anyway, this seems to be not a good idea.

Regards

Marcel

Re: [RFC] Add agent API to message atom

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3932 bytes --]

Hi Aki,

>>> This of course means that we need a bit more intelligent matching of the
>>> handled types. In general I am against the overhead of regex for this. I
>>> prefer glob style matching with just * and ?. That should be good
>>> enough. If you really need regex pattern matching then then I think a
>>> specialized oFono plugin with its own APIs is the way to go.
>>
>> This was basically what I was thinking, too, with the addition of ^
>> and $ for matching at the end or beginning of a message.
> 
> within GLib we have glob pattern matching functions, but nothing that
> additionally takes ^ and $. Why do you think this would be useful and
> needed? How many message agents to you expect to be running that are not
> using port numbers? Do you have some examples messages in mind?
> 

I'm still not seeing the usefulness of glob/regex matching for text
messages.  Are we dealing with some legacy SMS format, like RFC 2822
compatibility?  If so, making specific API might be better.

>>>> +Methods              void ImmediateMessage(string message, dict info)
>>>> +
>>>> +                     New immediate (class 0) SMS received.  Info has Sender,
>>>> +                     LocalSentTime, and SentTime information.  Sender
>>>> +                     address is given in string format.  LocalSentTime and
>>>> +                     SentTime are given in string form using ISO8601 format.
>>>
>>> Should these really be delivered via an agent?
>>
>> Why not?
> 
> These class 0 message are special and I think the home screen applet can
> just use the current D-Bus signal to deal with them. I don't think that
> we need special handling for them.
> 

I agree with Marcel here, immediate messages are destined for the home
screen and are not even tracked in history.

>>>> +             void IncomingMessage(string message, dict info)
>>>> +
>>>> +                     New incoming text SMS received.  Info has Sender,
>>>> +                     LocalSentTime, and SentTime information.
>>>> +
>>>> +             void IncomingPush(array{byte} message, dict info)
>>>> +
>>>> +                     New incoming push message received.  Info has Sender,
>>>> +                     LocalSentTime, SentTime, and ApplicationId information.
>>>> +
>>>> +             void IncomingApplication(array{byte} message, dict info)
>>>> +
>>>> +                     New incoming application message received.  Info has
>>>> +                     Sender, LocalSentTime, SentTime, DestinationPort, and
>>>> +                     SourcePort information.
>>>
>>> Why the difference between Push and Application. The dict could be
>>> easily used here to differentiate.
>>
>> True. And in fact we discussed this in IRC with Denis a bit and
>> decided that separating WAP push makes little sense overall. If the
>> agent needs to decode the WSP anyway, we're not providing much value
>> add in oFono just decoding the X-Wap-Application-Id header field. So
>> the agent might as well just use the application ports to register.
> 
> Personally I like the idea of doing the whole WSP decoding inside oFono,
> but if we have WAP Push over IP transport and the WAP Push daemon has to
> do the decoding again anyway, this seems to be not a good idea.

I said almost the same thing on IRC ;)

Someone also mentioned sending of binary SMS messages.  I want to avoid
giving applications ability to do that over D-Bus completely.  There are
only a few of these that are required, namely Send VCard and Send VCal,
so a dedicated set of methods would be better.  If we go in this
direction, then receiving VCards and VCals should also have dedicated
DBus API.

This leaves App/Port addressing useful for WSPs and maybe carrier
specific Visual Voicemail messages.  Given that, I'm not entirely
convinced RegisterApplicationAgent is a good idea...

Regards,
-Denis

Re: [RFC] Add agent API to message atom

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

Hi Marcel,

2010/8/31 Marcel Holtmann <marcel@holtmann.org>:
>> This was basically what I was thinking, too, with the addition of ^
>> and $ for matching at the end or beginning of a message.
>
> within GLib we have glob pattern matching functions, but nothing that
> additionally takes ^ and $. Why do you think this would be useful and
> needed? How many message agents to you expect to be running that are not
> using port numbers? Do you have some examples messages in mind?

There are services that use SMS to send confirmation tokens in
messages, and are not using application ports. But they also require
the ability to stop such a message ending up in the UI. So perhaps
this sort of thing is better done higher up the stack, like in the
messaging application itself.

Cheers,
Aki

Re: [RFC] Add agent API to message atom

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Hi Aki,

> >> This was basically what I was thinking, too, with the addition of ^
> >> and $ for matching at the end or beginning of a message.
> >
> > within GLib we have glob pattern matching functions, but nothing that
> > additionally takes ^ and $. Why do you think this would be useful and
> > needed? How many message agents to you expect to be running that are not
> > using port numbers? Do you have some examples messages in mind?
> 
> There are services that use SMS to send confirmation tokens in
> messages, and are not using application ports. But they also require
> the ability to stop such a message ending up in the UI. So perhaps
> this sort of thing is better done higher up the stack, like in the
> messaging application itself.

you really have to give me some concert examples here. The only time I
used these was for WiFi access tokens and these where expected to be
shown to the user.

So what kind of plain text messages need to be hidden from the UI? And
if we wanted to do that, what are the risk factors of accidentally
hiding them. Even with full blown regex pattern matching, I think there
is a high risk for false positives here.

I prefer if we are not doing that. If the services doesn't use port
numbers or some sort of WAP push to allow the device to uniquely
identify its message, then there is something seriously wrong with that
service.

Even just starting to think about the security implications here makes
me kinda worry. My thinking is that oFono should not look into the
content of any messages until it is a clearly defined protocol or
format.

Regards

Marcel

RE: [RFC] Add agent API to message atom

[Zhang, Caiwen]

[-- Attachment #1: Type: text/plain, Size: 4623 bytes --]

Hi Aki，


> ---
>  doc/message-api.txt |   97
> +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 97 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/message-api.txt b/doc/message-api.txt
> index 693a111..ce96315 100644
> --- a/doc/message-api.txt
> +++ b/doc/message-api.txt
> @@ -26,6 +26,66 @@ Methods		dict GetProperties()
> 
>  			Send the message in text to the number in to.
> 
> +		void RegisterTextAgent(object path, string match)
> +
> +			Registers an agent to receive messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when a message is ready to be
> +			dispatched.  The match parameter takes an optional
> +			matching rule in a restricted subset of regular
> +			expression syntax.
> +
> +			TODO: accepted regexp syntax.  Perhaps only allow
> +			simple match rules for the beginning and end of a
> +			message, as well as a free text token match for the
> +			entire message.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
> +		void RegisterPushAgent(object path, string id)
> +
> +			Registers an agent to receive push messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when a push message is ready to be
> +			dispatched.  The id parameter takes an optional
> +			WAP application ID that is used to match incoming
> +			push messages.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
> +		void RegisterApplicationAgent(object path, uint dest, uint
> src)
> +
> +			Registers an agent to receive application messages.
> +
> +			The object path defines the path of the agent that
> +			will be called when an application message is ready
> +			to be dispatched.
> +
> +			The dest parameter is the destination application
> +			port number, and the src parameter is the optional
> +			source application port number.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.InUse
> +
Push message is a kind of application message. If an agent register both
RegisterPushAgent and RegisterApplicationAgent, will the message be processed
Twice. Will you offer same way to avoid this?

> +		void UnregisterAgent(object path)
> +
> +			Unregisters an agent.  If no agent is registered
> +			that matches the type of an arriving message, it is
> +			silently dropped.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.InvalidFormat
> +					 [service].Error.NotFound
> +					 [service].Error.NotAuthorized
> +
>  Signals		PropertyChanged(string name, variant value)
> 
>  			This signal indicates a changed value of the given
> @@ -64,3 +124,40 @@ Properties	string ServiceCenterAddress
>  				"ps-preferred" - Use CS if PS is unavailable
> 
>  			By default oFono uses "cs-preferred" setting.
> +
> +
> +MessageAgent Hierarchy [experimental]
> +===============
> +
> +Service		unique name
> +Interface	org.ofono.MessageAgent
> +Object path	freely definable
> +
> +Methods		void ImmediateMessage(string message, dict info)
> +
> +			New immediate (class 0) SMS received.  Info has
> Sender,
> +			LocalSentTime, and SentTime information.  Sender
> +			address is given in string format.  LocalSentTime and
> +			SentTime are given in string form using ISO8601
> format.
> +
> +		void IncomingMessage(string message, dict info)
> +
> +			New incoming text SMS received.  Info has Sender,
> +			LocalSentTime, and SentTime information.
> +

Is the 'message' the text content of the income message(I mean the decoded user data)?

> +		void IncomingPush(array{byte} message, dict info)
> +
> +			New incoming push message received.  Info has Sender,
> +			LocalSentTime, SentTime, and ApplicationId
> information.
> +
> +		void IncomingApplication(array{byte} message, dict info)
> +
> +			New incoming application message received.  Info has
> +			Sender, LocalSentTime, SentTime, DestinationPort, and
> +			SourcePort information.
> +

Is the 'message' the whole PDU or only the user data? 

> +		void Release()
> +
> +			Agent is being released, possibly because of oFono
> +			terminating, the MessageManager interface being torn
> +			down or modem powering down.
> --
> 1.7.0.4
> 

Will you consider send push message and application message?

Thanks!

Best regards,
Caiwen

Re: [RFC] Add agent API to message atom

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

Hi,

2010/8/31 Zhang, Caiwen <Caiwen.Zhang@windriver.com>:
>> +             void RegisterApplicationAgent(object path, uint dest, uint
>> src)
>> +
>> +                     Registers an agent to receive application messages.
>> +
>> +                     The object path defines the path of the agent that
>> +                     will be called when an application message is ready
>> +                     to be dispatched.
>> +
>> +                     The dest parameter is the destination application
>> +                     port number, and the src parameter is the optional
>> +                     source application port number.
>> +
>> +                     Possible Errors: [service].Error.InvalidArguments
>> +                                      [service].Error.InvalidFormat
>> +                                      [service].Error.InUse
>> +
> Push message is a kind of application message. If an agent register both
> RegisterPushAgent and RegisterApplicationAgent, will the message be processed
> Twice. Will you offer same way to avoid this?

I think we'll just have a single ApplicationAgent interface that works
with app ports. I was thinking it would be elegant to be able to
register an agent only using the WAP app ID, but perhaps that's just a
waste of time.

>> +             void IncomingMessage(string message, dict info)
>> +
>> +                     New incoming text SMS received.  Info has Sender,
>> +                     LocalSentTime, and SentTime information.
>> +
>
> Is the 'message' the text content of the income message(I mean the decoded user data)?

Just the body of the message (UTF-8 string), just like in the signals.

>> +             void IncomingPush(array{byte} message, dict info)
>> +
>> +                     New incoming push message received.  Info has Sender,
>> +                     LocalSentTime, SentTime, and ApplicationId
>> information.
>> +
>> +             void IncomingApplication(array{byte} message, dict info)
>> +
>> +                     New incoming application message received.  Info has
>> +                     Sender, LocalSentTime, SentTime, DestinationPort, and
>> +                     SourcePort information.
>> +
>
> Is the 'message' the whole PDU or only the user data?

The user data excluding the user data header, which we decode and
provide in the dict.

>> +             void Release()
>> +
>> +                     Agent is being released, possibly because of oFono
>> +                     terminating, the MessageManager interface being torn
>> +                     down or modem powering down.
>> --
>> 1.7.0.4
>>
>
> Will you consider send push message and application message?

Ah, good point. Yes, we obviously need to support sending binary
messages as well.

Cheers,
Aki