Re: [Fwd: Re: Another 1.2.3 candidate bug - #1838]

Hello Dmitriy,

Tuesday, February 13, 2007, 12:35:32 PM, you wrote:

> Hello Paul,

> On Tue, 13 Feb 2007, Paul Sokolovsky wrote:

>> Date: Tue, 13 Feb 2007 11:28:11 +0200
>> From: Paul Sokolovsky <pmiscml_at_gmail.com>
>> To: Dmitriy Korovkin <korovkin_at_tochka.ru>
>> Cc: opie-devel_at_handhelds.org
>> Subject: Re: [Fwd: Re: [Opie-devel] Another 1.2.3 candidate bug - #1838]
>>
>> Hello Dmitriy,
>>
>> Tuesday, February 13, 2007, 8:35:45 AM, you wrote:
>>
>>> Rene, Erik,
>>> Let me try to explain the situation:
>>> Bluetooth Manager (noncore/net/opietooth/manager), accompanied by
>>> noncore/net/opietooth/lib is the application that is a configuration
>>> tool that allows you to edit /etc/bluetooth/hcid.conf and
>>> /etc/bluetooth/rfcomm.conf with the proper GUI. It also allows you to
>>> scan and discover BT devices.
>>> Now the provided patch adds another configuration file:
>>> /etc/sysconfig/bluetooth.
>>
>> Nope, it doesn't add it. It already exists as system config.
> Yes, but this requires Familiar maintainers generate these files for each
> handheld model. It may cause problems. h5400 != h3800, for instance.
> So, this file will be edited with probability > 50%, so the configuration
> tool is required.

  As I told, such tool exists - it's blueprobe. It's maintainer not by
Familiar, but by GPE:

http://handhelds.org/cgi-bin/cvsweb.cgi/gpe/base/blueprobe/blueprobe.init?rev=1.12&content-type=text/x-cvsweb-markup
http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/trunk/base/blueprobe/blueprobe.init?rev=8948&root=gpe&view=auto

  Note that it is not a GPE component per se, it's just nice script to
do detection, which just maintainer by GPE folks. We obviously should
reuse it - it's nice case of cross-project synergy (difference in UI
toolkits shouldn't lead to reinventing base system).

>>
>>> My oppinion: if we have one more conf file, we
>>> need to provide a tool that allows us, (not us, we know how to do this
>>> -- a user) to configure it.
>>
>> Patches welcome ;-).
> I had it in my plans. If it's urgent and you insist that we have to apply
> this config in 1.2.3, I'll try to do it this weekend, it's not a big deal.
> The only thing I really need - a list of possible handheld configurations
> to give a user a list to chose.

  Well, I can't insist, as I'm not even OPIE maintainer. But IMHO it's easy
thing which gives much effect. And not just pure technical, but
organizational/PR. We now can say that OPIE now supports any handheld
with BT model, and that will be true. Even if there's a new port, it's
much easier to edit single config file (manually), then crawl thru
big C++ system, to find place where you need to patch code.

  As for frontend, and if you ask me, I would really think that much
better investment of your time in this release time would be to
collect and document 3rd party dependencies/requirements, and to
test/debug existing features.

>>
>>> This means that we need another dialog box
>>> in the BT manager.
>>> This is my idea.
>>
>> Yes, but it puts too big requirements on BT manager maintainer ;-).
> I'll survive.
>> I offer simple organizational solution for such kind of problems:
>> user-level configs better be edited in GUI, system-level - highly
>> optionally.
>>
>>
>>
>> Anyway, now that we spoke of Bluetooth at all, Dmitriy, is there
>> somewhere list of 3rd party requirements for OPIE Bluetooth support?
>> Like, what versions of bluez, different obex tools, etc., it expects?
>> I didn't find such info from http://opie.handhelds.org/cgi-bin/moin.cgi/OpieBluetooth
>> (but surprisingly I found that BT applet "Takes configuration for BT
>> device from /etc/sysconfig/bluetooth")

> Currently OPIE has it's own OBEX support.

  Well, this doesn't correspond to what I see in OE.dev. There,
different utils based on OpenObex are used to handle both sending and
receiving. But what's weird is that set of tools both IrDA and BT
differs (even though they are still based on OpenObex). For example,
IrDA receive is handled by irobex_palm3, and received stuff properly
picked up by by PIM suite. BT receive is handled by opd, and it does
receive properly to /tmp, but stuff is not picked up by OPIE -
apparently, there's no/broken communication means between there.

  So, what's wrong in this picture? Is it OE.dev broken or there's not
all perfect on OPIE side? I don't have clear idea where to start. If
Familiar tree is authority here, I can look into it, but it's still
would be better if OPIE provided docs on integration requirements (of
course, such doc would be elaborated together with distros).

> If Familiar moves to newer bluez, it's good to add a support to hcid
> configuration that set's up how long the device is scannable by others.
> Just let me know.

  I don't know about Familiar, unfortunately - there's big lack of
info where it moves, and if moves at all ;-(. But OE.dev did switch to
bluez 3.x, and moreover bluez 2.x was removed from it. My request to
put it back was declined on the basis that bluez2 and bluez3 cannot
peacefully coexist. One adverse effect of bluez3 is that it forces to
use D-Bus: pin agents have no other means to communicate with hcid
apart from using D-Bus. This brings questions: was addition of D-Bus
to OPIE ever discussed? Is there someone who interested to do that?

-- 
Best regards,
 Paul                            mailto:pmiscml_at_gmail.com