Re: [Bluez-devel] CUPS plugin discovery bits

["Luiz Augusto von Dentz" <luiz.dentz@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2985 bytes --]

Comments in line:

On 5/29/07, Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2007-05-29 at 00:58 -0300, Luiz Augusto von Dentz wrote:
> > I consider this as a wizard for printers, like in NetwokManager the
> > network wizard also
> > does start a discovery and it work like a charm but in my opinion it
> > doesnt belong to bluez utils.
>
> It's a standard feature of cups backends. If they support it, they
> should list the accessible/known printers in the vicinity.
>
> > Having each wizard to rely in its own discovery is probably a bad
> > design, we can probably integrate
> > all wizard together and then having services configuring them in the
> > background. This way we
> > could leave to the user to use periodic scan and popup specific device
> > wizard dependent on
> > each service when active. Also in my opinion it should exist a printer
> > service for those that want to
> > configure its devices that are not in discoverable mode.
>
> True, it would be much better. But in the meanwhile, this patch simply
> implements a CUPS feature and allows us to have some basic integration
> in the distribution-provided printer tools.


So we may mark this as subject to change.

Being able to configure the printer via a bluetooth configuration wizard
> requires a bit more work, but it's also on my plans. There should be a
> CUPS service that would allow hcid to add/remove bluetooth printers from
> cups with minimum user interaction.


My idea is to have printer service more generic, the bluetooth wizard could
do
CUPS integration as it would integrate with any other system wide
integration.

> Btw, The printer wizard as it is now wont work with periodic
> > discovery, signals DiscoveryStarted and
> > DiscoveryCompleted are not emitted while in periodic  discovery.
>
> The cups backend isn't supposed to run forever, so it can't do periodic
> discovery.


Well that is not the case of being running forever but you could probably
test if the periodic scan is active before you start a blocking discovery.
My main concern is about multiple process doing this, the probability of
having collisions while doing sdp searches could be very high as it is very
common to have more than one functionality in a device, this leaves wizard
processes very complicated and may force them to reschedule on each
collision .

--
> Bastien Nocera <hadess@hadess.net>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>



-- 
Luiz Augusto von Dentz
Engenheiro de Computação

[-- Attachment #1.2: Type: text/html, Size: 4072 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel