Hi folks,
I would like to bring up the device configuration services before start
coding, I would like design how these services will work and receive
comments.
The services provided under these paths/interfaces will not be public. Only
an administrator group or a root will be allowed to send messages. We don't
need care about the configuration file rules now, it can be defined later.
In my opinion it's better use the same approach of the Manager. A main path
object "/org/bluez/Manager" (FALLBACK) should catch messages sent to
unregistered
paths and handle services like:
- DeviceList, displays UP/DOWN devices
- UP
- DOWN
- RESET
The device based paths can provide services like:
- SetProperty
- GetProperty
- Commands
- Features
Using SetProperty/GetProperty instead of define one method name for each
property is more clean. However it is important keep in mind that the
documentation of this service must be well-defined, because the method
call/method reply arguments will have different argument number and types.
In the method call, the first argument must be a byte(faster comparison)
indicating the command code instead of use a string to represent the
command.
Suggested paths and Interfaces:
*** Main path
path:
/org/bluez/Devices
interface: org.bluez.Devices
*** Device based
path:
/org/bluez/Devices/hciX
interface: org.bluez.Devices
Another point is the message handler function. Currently, there is only one
function responsible for handle the messages. In my opinion it will be
better
create other DBusObjectPathVTable to address Device messages for make the
logic more clear. For SetProperty/GetProperty will be required extract the
first argument to get the command code in the message handle function.
Is everything ok? Any comments?
Regards,
Claudio.
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
Hi Eduardo,
> I've changed the functions names. Here is the patch.
the patch is now in the CVS. Thanks.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> here is some code cleanup. This patch should be applied after the
> dbus_device.patch.
the patch is now in the CVS, but I had to fix "if (sk > 0)" ;)
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is some code cleanup. This patch should be applied after the
dbus_device.patch.
BR,
Eduardo.
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
On 10/25/05, Johan Hedberg <[email protected]> wrote:
> On Tue, Oct 25, 2005, Eduardo Rocha wrote:
> > The point is, as we have merged the main operations in two functions (set
> > and get), so we have to identify the operation by an integer or by a string
> > constant. It seems that a string is better for python binding (can anyone
> > confirm that?).
>
> At least by using strings it would be much easier to understand what the
> client code is doing, e.g. if you compare
> SetProperty("page-timeout", 10)
> vs.
> SetProperty(3, 10)
>
> So, I vote for using strings instead of integers.
>
> Johan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
On Tue, Oct 25, 2005, Eduardo Rocha wrote:
> The point is, as we have merged the main operations in two functions (set
> and get), so we have to identify the operation by an integer or by a string
> constant. It seems that a string is better for python binding (can anyone
> confirm that?).
At least by using strings it would be much easier to understand what the
client code is doing, e.g. if you compare
SetProperty("page-timeout", 10)
vs.
SetProperty(3, 10)
So, I vote for using strings instead of integers.
Johan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Basically the services under the path "/org/bluez/Devices" will
provide a way to userspace applications setup the devices, a similar
functionality provided by hciconfig. The security issues will be handled by
the D-Bus configuration file.
Regarding the SetProperty/GetProperty...
There are a lot of commands that we intend provide: up, down, reset, rstat,
auth, noauth, encrypt, ....
My initial suggestion was divide the services into TWO groups:
* Device independant, path: /org/bluez/Devices, interface: path:
org.bluez.Devices
Services:
- Up
- Down
- Reset
* Device Based services, path: /org/bluez/Devices/hciX, interface: path:
org.bluez.Devices
Services:
- auth
- noauth
- encrypt
- noencrypt
- secmgr
- nosecmgr
- piscan
- noscan
- iscan
- pscan
...
In order to make the API more clean, the device based services will use the
method
name(SerProperty/GetProperty), where the first message argument is the
command
identification (auth, noauth, encrypt,...)
The question is: if we use an String representation of the command the
client coding
will be more "legible" by other hand the hcid message argument
extracting/comparison
will be more expensive than extract a byte or a integer. Which approach do
you prefer?
Regards,
Claudio
On 10/24/05, Marcel Holtmann <[email protected]> wrote:
>
> Hi Eduardo,
>
> > here is the initial patch regarding /org/bluez/Devices. I keep it
> > really simple so we can improve it in small steps. I've merged the
> > Claudio's code for register and unregister a new path for a device in
> > two funcions as this code is used in 3 different parts of the code.
>
> call it *register_device() and *register_manager().
>
> > For now I've leaved the syslog call to register and unregister
> > operations so we can see if every thing is going ok.
>
> I think it is a good idea to introduce some DBG() defines.
>
> > My next step is to provide a list of registed devices (not only the
> > devices that are up) through /org/bluez/Devices path.
>
> Feel free to send another patch on top of this one.
>
> > One question: the SetProperty and GetProperty will use an interger or
> > a string constant to determing which operation will be used?
>
> You need to explain to me what you are talking about.
Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Marcel,
I've changed the functions names. Here is the patch.
About the SetProperty:
Claudio said: " The device based paths can provide services like:
- SetProperty
- GetProperty
- Commands
- Features
Using SetProperty/GetProperty instead of define one method name for each
property is more clean. However it is important keep in mind that the
documentation of this service must be well-defined, because the method
call/method reply arguments will have different argument number and types.
In the method call, the first argument must be a byte(faster comparison)
indicating the command code instead of use a string to represent the
command"
The point is, as we have merged the main operations in two functions (set
and get), so we have to identify the operation by an integer or by a string
constant. It seems that a string is better for python binding (can anyone
confirm that?).
BR,
Eduardo.
On 10/24/05, Marcel Holtmann <[email protected]> wrote:
>
> Hi Eduardo,
>
> > here is the initial patch regarding /org/bluez/Devices. I keep it
> > really simple so we can improve it in small steps. I've merged the
> > Claudio's code for register and unregister a new path for a device in
> > two funcions as this code is used in 3 different parts of the code.
>
> call it *register_device() and *register_manager().
>
> > For now I've leaved the syslog call to register and unregister
> > operations so we can see if every thing is going ok.
>
> I think it is a good idea to introduce some DBG() defines.
>
> > My next step is to provide a list of registed devices (not only the
> > devices that are up) through /org/bluez/Devices path.
>
> Feel free to send another patch on top of this one.
>
> > One question: the SetProperty and GetProperty will use an interger or
> > a string constant to determing which operation will be used?
>
> You need to explain to me what you are talking about.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Eduardo,
> here is the initial patch regarding /org/bluez/Devices. I keep it
> really simple so we can improve it in small steps. I've merged the
> Claudio's code for register and unregister a new path for a device in
> two funcions as this code is used in 3 different parts of the code.
call it *register_device() and *register_manager().
> For now I've leaved the syslog call to register and unregister
> operations so we can see if every thing is going ok.
I think it is a good idea to introduce some DBG() defines.
> My next step is to provide a list of registed devices (not only the
> devices that are up) through /org/bluez/Devices path.
Feel free to send another patch on top of this one.
> One question: the SetProperty and GetProperty will use an interger or
> a string constant to determing which operation will be used?
You need to explain to me what you are talking about.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Sorry about the spaces. Here is the same patch without them ;).
BR,
Eduardo.
On 10/24/05, Eduardo Rocha <[email protected]> wrote:
>
> Hi Claudio and Marcel,
>
> here is the initial patch regarding /org/bluez/Devices. I keep it really
> simple so we can improve it in small steps. I've merged the Claudio's code
> for register and unregister a new path for a device in two funcions as this
> code is used in 3 different parts of the code. For now I've leaved the
> syslog call to register and unregister operations so we can see if every
> thing is going ok.
> My next step is to provide a list of registed devices (not only the
> devices that are up) through /org/bluez/Devices path.
>
> One question: the SetProperty and GetProperty will use an interger or a
> string constant to determing which operation will be used?
>
> BR,
> Eduardo
> --
> Eduardo Rocha
> Instituto Nokia de Tecnologia - INdT
>
> On 10/19/05, Claudio Takahasi <[email protected]> wrote:
> >
> > Hi folks,
> >
> > I would like to bring up the device configuration services before start
> > coding, I would like design how these services will work and receive
> > comments.
> >
> > The services provided under these paths/interfaces will not be public.
> > Only
> > an administrator group or a root will be allowed to send messages. We
> > don't
> > need care about the configuration file rules now, it can be defined
> > later.
> >
> > In my opinion it's better use the same approach of the Manager. A main
> > path
> > object "/org/bluez/Manager" (FALLBACK) should catch messages sent to
> > unregistered
> > paths and handle services like:
> > - DeviceList, displays UP/DOWN devices
> > - UP
> > - DOWN
> > - RESET
> >
> > The device based paths can provide services like:
> > - SetProperty
> > - GetProperty
> > - Commands
> > - Features
> >
> > Using SetProperty/GetProperty instead of define one method name for each
> > property is more clean. However it is important keep in mind that the
> > documentation of this service must be well-defined, because the method
> > call/method reply arguments will have different argument number and
> > types.
> > In the method call, the first argument must be a byte(faster comparison)
> > indicating the command code instead of use a string to represent the
> > command.
> >
> > Suggested paths and Interfaces:
> > *** Main path
> > path:
> > /org/bluez/Devices
> > interface: org.bluez.Devices
> >
> > *** Device based
> > path:
> > /org/bluez/Devices/hciX
> > interface: org.bluez.Devices
> >
> >
> > Another point is the message handler function. Currently, there is only
> > one
> > function responsible for handle the messages. In my opinion it will be
> > better
> > create other DBusObjectPathVTable to address Device messages for make
> > the
> > logic more clear. For SetProperty/GetProperty will be required extract
> > the
> > first argument to get the command code in the message handle function.
> >
> >
> > Is everything ok? Any comments?
> >
> > Regards,
> > Claudio.
> >
> > --
> > ---------------------------------------------------------
> > Claudio Takahasi
> > Nokia's Institute of Technology - INdT
> > [email protected]
> >
>
>
>
>
>
>
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Claudio and Marcel,
here is the initial patch regarding /org/bluez/Devices. I keep it really
simple so we can improve it in small steps. I've merged the Claudio's code
for register and unregister a new path for a device in two funcions as this
code is used in 3 different parts of the code. For now I've leaved the
syslog call to register and unregister operations so we can see if every
thing is going ok.
My next step is to provide a list of registed devices (not only the devices
that are up) through /org/bluez/Devices path.
One question: the SetProperty and GetProperty will use an interger or a
string constant to determing which operation will be used?
BR,
Eduardo
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
On 10/19/05, Claudio Takahasi <[email protected]> wrote:
>
> Hi folks,
>
> I would like to bring up the device configuration services before start
> coding, I would like design how these services will work and receive
> comments.
>
> The services provided under these paths/interfaces will not be public.
> Only
> an administrator group or a root will be allowed to send messages. We
> don't
> need care about the configuration file rules now, it can be defined later.
>
> In my opinion it's better use the same approach of the Manager. A main
> path
> object "/org/bluez/Manager" (FALLBACK) should catch messages sent to
> unregistered
> paths and handle services like:
> - DeviceList, displays UP/DOWN devices
> - UP
> - DOWN
> - RESET
>
> The device based paths can provide services like:
> - SetProperty
> - GetProperty
> - Commands
> - Features
>
> Using SetProperty/GetProperty instead of define one method name for each
> property is more clean. However it is important keep in mind that the
> documentation of this service must be well-defined, because the method
> call/method reply arguments will have different argument number and types.
> In the method call, the first argument must be a byte(faster comparison)
> indicating the command code instead of use a string to represent the
> command.
>
> Suggested paths and Interfaces:
> *** Main path
> path:
> /org/bluez/Devices
> interface: org.bluez.Devices
>
> *** Device based
> path:
> /org/bluez/Devices/hciX
> interface: org.bluez.Devices
>
>
> Another point is the message handler function. Currently, there is only
> one
> function responsible for handle the messages. In my opinion it will be
> better
> create other DBusObjectPathVTable to address Device messages for make the
> logic more clear. For SetProperty/GetProperty will be required extract the
> first argument to get the command code in the message handle function.
>
>
> Is everything ok? Any comments?
>
> Regards,
> Claudio.
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Nokia's Institute of Technology - INdT
> [email protected]
>