From: Suraj Sumangala <suraj@Atheros.com>
To: <linux-bluetooth@vger.kernel.org>,
<Jothikumar.Mothilal@Atheros.com>,
<joakim.xj.ceder@stericsson.com>, <claudio.takahasi@gmail.com>,
<Waldemar.Rymarkiewicz@tieto.com>, <Arkadiusz.Lichwa@tieto.com>
Subject: Re: [RFC] Sim Access Profile API doc
Date: Tue, 7 Sep 2010 15:28:22 +0530 [thread overview]
Message-ID: <4C860CBE.8060808@Atheros.com> (raw)
In-Reply-To: <20100907092927.GA28640@jh-x301>
Hi Johan,
On 9/7/2010 2:59 PM, Johan Hedberg wrote:
> Hi Suraj,
>
> On Tue, Sep 07, 2010, Suraj Sumangala wrote:
>> +Methods void RegisterAgent(object agent)
>> +
>> + This registers the Sim Access adapter agent.
>> + This also registers the profile with the service
>> + Databse and start waiting for an RFCOMM connection
>> + on the SAP server channel.
>> +
>> + The object path defines the path the of the agent.
>> +
>> + If an application disconnects from the bus all
>> + of its registered agents will be removed.
>> +
>> + Possible errors: org.bluez.Error.InvalidArguments
>> + org.bluez.Error.AlreadyExists
>> + org.bluez.Error.Failed
>> +
>> + void UnregisterAgent(object agent)
>> +
>> + This unregisters the agent that has been previously
>> + registered. The object path parameter must match the
>> + same value that has been used on registration.
>> +
>> + Possible errors: org.bluez.Error.DoesNotExist
>> + org.bluez.Error.InvalidArguments
>> + org.bluez.Error.Failed
>
> So you have these nice agent registration methods, however where's the
> definition of the agent interface? And if you're going to use an agent
> for this (which seems like a good idea) the SAP commands should map to
> D-Bus method calls to the agent and the D-Bus method replies from the
> agent should map to the SAP replies. I.e. please get rid of the D-Bus
> signals and methods you currently have for this.
The idea was to let the agent implementation be written depending on the
actual SIM card reader implementation used in the back end. The agent
can then map its signal/methods to the corresponding SAP server calls.
>
> Btw, I'm not 100% convinced that this is the most sensible architecture
> for implementing SAP, but assuming that it is the above comments apply
> :)
Yep, I understand. There were doubts raised on this methods. That is the
reason why I thought about getting comments from the community.
Your comments are most welcome.
>
> Johan
Regards
Suraj
next prev parent reply other threads:[~2010-09-07 9:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 6:02 [RFC] Sim Access Profile API doc Suraj Sumangala
2010-09-07 7:47 ` Uwe Kleine-König
2010-09-07 8:36 ` Waldemar.Rymarkiewicz
2010-09-07 9:28 ` Suraj Sumangala
2010-09-07 12:24 ` Waldemar.Rymarkiewicz
2010-09-07 9:29 ` Johan Hedberg
2010-09-07 9:58 ` Suraj Sumangala [this message]
2010-09-07 10:12 ` Johan Hedberg
2010-09-07 12:54 ` Suraj Sumangala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C860CBE.8060808@Atheros.com \
--to=suraj@atheros.com \
--cc=Arkadiusz.Lichwa@tieto.com \
--cc=Jothikumar.Mothilal@Atheros.com \
--cc=Waldemar.Rymarkiewicz@tieto.com \
--cc=claudio.takahasi@gmail.com \
--cc=joakim.xj.ceder@stericsson.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).