Hi, On Fri, Jun 10, 2011 at 4:18 AM, Gustavo F. Padovan <padovan@xxxxxxxxxxxxxx> wrote: > * Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> [2011-06-09 21:38:22 +0900]: > >> Hi Marcel, >> >> On Thu, Jun 9, 2011 at 7:24 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: >> > Hi Waldemar, >> > >> >> The method is called if min. 16 bytes pincode is mendatory >> >> to authenticate connection. >> >> >> >> In practice this will be called only with mgmtops switched on. Hciops >> >> don't support secure pin code so far. >> >> --- >> >> doc/agent-api.txt | 11 +++++++++++ >> >> 1 files changed, 11 insertions(+), 0 deletions(-) >> >> >> >> diff --git a/doc/agent-api.txt b/doc/agent-api.txt >> >> index 9ab2063..b1cb354 100644 >> >> --- a/doc/agent-api.txt >> >> +++ b/doc/agent-api.txt >> >> @@ -31,6 +31,17 @@ Methods void Release() >> >> Possible errors: org.bluez.Error.Rejected >> >> org.bluez.Error.Canceled >> >> >> >> + string RequestSecurePinCode(object device) >> >> + >> >> + This method gets called when the service daemon >> >> + needs to get the secure passkey for an authentication. >> >> + >> >> + The return value should be a string of 16 characters >> >> + length. The string can be alphanumeric. >> >> + >> >> + Possible errors: org.bluez.Error.Rejected >> >> + org.bluez.Error.Canceled >> >> + >> > >> > I do not like this since it is really legacy stuff and makes since >> > really complicated. And now we are making big efforts to support this >> > and that is bad. Since Simple Pairing solved this nicely for us. >> > >> > However I need to talk with Johan about this and figure something out. >> >> We are getting closer to 4.100, maybe it is time to start doing the >> transition to 5.x, which means we could start thinking on fixing the >> current API without worrying if it breaks or not. How about that? > > I'm with Luiz here. Unless we want the the crazy idea of have a development > branch we should start breaking the API someday. How about now? > > And if we are really going for it a roadmap made public somewhere would be > good. :) Actually we can do it without breaking 4.x API like we did with 3.x where both API lives side by side until we decide it is stable enough, to do that we can have the new API having a different interface prefix e.g. org.bluez5 or just have a different connection with same interfaces names, the 1 option is less complicated for bluetoothd but requires more work on the client side while the second is more complicated for the daemon while the client just need to change the bus id. -- Luiz Augusto von Dentz Computer Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
