pc_server-hal brach merging strategy

[caval...@gmail.com]

Friends

Thiago have done a nice work refactoring the main server loop in amora
pc_server-hal
branch, with the positive side-effect of supporting multiple clients.

I think this code should be merged with the trunk, so Amora 1.0
release could support multiple devices (since it was successfully
tested with 3 devices at same time).

Concerning HAL/D-BUS dongle removing event trapping, it is still not
solved (porting dependencies, different behavior between kernel
versions and distributions). I think it should be delayed to Amora 1.1
version.

Just to remember, there is a roadmap for the project (and I think we
should make a new release at ending of first january week).
http://code.google.com/p/amora/wiki/roadmap

As you can see there, the priorities are: server code cleanup,
packaging and mobile client user interface improvements.

What do you guys think about it?


Best regards


Adenilson

[Ademar de Souza Reis Jr.]

On Dec 12, 2007 3:16 PM, <caval...@gmail.com> wrote:
>
> Friends
>

Hi there.

> Thiago have done a nice work refactoring the main server loop in amora
> pc_server-hal
> branch, with the positive side-effect of supporting multiple clients.
>
> I think this code should be merged with the trunk, so Amora 1.0
> release could support multiple devices (since it was successfully
> tested with 3 devices at same time).

I like the idea of merging the branch before 1.0. Just make sure it's
well tested before releasing the 1.0 version, otherwise call it 0.10
:-)

>
> Concerning HAL/D-BUS dongle removing event trapping, it is still not
> solved (porting dependencies, different behavior between kernel
> versions and distributions). I think it should be delayed to Amora 1.1
> version.

I was discussing this with Thiago: maybe it would be better to use
bluez-dbus API instead of hald. But of course I have no idea of how it
would be ported to BSD.

> As you can see there, the priorities are: server code cleanup,
> packaging and mobile client user interface improvements.

I added a rpm .spec file (for Mandriva Linux) to the repository some
days ago, so packaging for other rpm-based distros should be trivial
(amora-server is in Mandriva Cooker already).

What about changing the project names to amora-client and amora-server
(configure.ac) before the 1.0 version? It would be more standard and
allow better packaging.

Cheers,
- Ademar

--
Ademar de Souza Reis Jr. <ade...@ademar.org>
http://www.ademar.org/
http://blog.ademar.org/

^[:wq!

[caval...@gmail.com]

Ademar

I didn't know that amora server was included in Mandriva repositories
(really cool!).
:-)

Concerning the directory naming, I agree with the changes (as long it
will make
packaging effort easier).


Regards


Adenilson

[Thiago Marcos P. Santos]

On Dec 12, 4:28 pm, "Ademar de Souza Reis Jr." <ademar.r...@gmail.com>
wrote:

Hi all,

Unfortunately HAL isn't mature enough to be integrated with amora-
server. In every distinct environment, the bluetooth dongle is detect
in a different way. The code that was committed in pc_server-hal
branch is working fine in my Debian Etch workstation until I update
the kernel to 2.6.22. So, we must find another way to detect dongle
removal.

My suggestion, as discussed with Ademar is to use DBUS events sent by
the bluetooth daemon in the same way as Gnome Bluetooth Applet works.
This will added a dependence of bluetooth daemon (not a library
dependence, but this daemon must be running). This isn't a problem
since all main distros this daemon is running by default. I'll try to
finish this code ASAP (till sunday, I will work on it this weekend),
but we can merge the main_loop code as Amora 0.10.

I hope that someday when bluetooth dongle detection is working fine
with HAL we can revert this decision. Seems to FreeBSD is also using
HAL [1] and AFAIK the dongle detection implemented through bluetooth
daemon will be linux-only.

Regarding the name change I totally agree with this. To be even more
compliant with *nix subculture, I would like to suggest the name
amorad to server binary and amora.py to client script. My suggestion
of the repository structure is:

Official name: Amora Client
Script name: amora.py
Repository dir: trunk/amora-client/

Official name: Amora Server
Binary name: amorad
Repository dir: trunk/amora-server/

BR,

[1] http://www.freshports.org/sysutils/hal/

[caval...@gmail.com]

Friends


Merging of uLoop code was completed in r308 and renaming directory
structure in r313. The directory structure now is:
|... trunk
.......... amora-client
.......... amora-server

HAL/DBUS support was postponed for Amora release 1.1.

I think this closes the whole story.
:-)

Best regards


Adenilson