Linux bluetooth development
 help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@qualcomm.com>
To: Marcel Holtmann <marcel@rvs.uni-bielefeld.de>
Cc: Stephen Crane <steve.crane@rococosoft.com>,
	Philip Blundell <pb@nexus.co.uk>,
	BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: Version 3 libs/utils
Date: Thu, 26 Jun 2003 10:15:22 -0700	[thread overview]
Message-ID: <5.1.0.14.2.20030626094614.0dadee68@unixmail.qualcomm.com> (raw)
In-Reply-To: <1056543354.10001.136.camel@pegasus>

At 05:15 AM 6/25/2003, Marcel Holtmann wrote:
>Hi Max,
>Hi Stephen,
>
>> I think branch is CVS branch is probably a bad idea. Because we want
>> to change a lot of things like command names, etc. Which means lots 
>> of file renames, CVS does not handle that.
>> 
>> How about creating completely new modules
>>         libs2 
>>         utils2
>> and start with the clean history.
>> We'll keep old ones around for a while but will only make minor fixes
>> to them.
>
>we have already discussed this and starting with new modules seemed to
>be the cleanest way. But we shouldn't name them libs2 and utils2,
>because we are already at version 2.x with the others. We should use
>libs3 and utils3 or maybe an unrelated to the version number suffix like
>"-ng".
I think version number of the current packages and '2' in libs2,utils2 are 
unrelated. '2' just means second generation or something. New packages will 
have new version numbers anyway.

So I vote for utils2 and libs2. People are used to things like glib2, libxml2.
libs3 would be something unusual :)

>If we agree on the new name, I will start to create the framework for the new modules.
Let's talk about the goals and objectives first.

Here is the list of things that I have in mind

1. API cleanup and redesign if necessary
        Better function names, etc.

2. Better hotplug support
        Device initialization via hotplug scripts
        /etc/hotplug/bluetooth.agent, /etc/sysconfig/bluetooth, etc.

3. Neighborhood and security databases and API for them
        Device names, PIN codes, Link keys, etc
        Tools to access and modify those databases

4. Integrated SDP.

5. Better (more appropriate) names for Bluetooth command line utilities and daemons.
        hciconfig -> btconfig
        rfcomm -> btport
        sdpd -> btsdpd
        etc

6. Improved PIN helper support
        D-Bus or something similar.

7. Improved documentation. 
        At least DoxyGen on headers and sources.

Comments ? Other ideas ?

Max

  reply	other threads:[~2003-06-26 17:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-19 16:42 [Bluez-devel] patch for d-bus support in hcid Philip Blundell
2003-06-20 16:19 ` David Woodhouse
2003-06-21  0:13 ` Max Krasnyansky
2003-06-24 14:00   ` Version 3 libs/utils (was: Re: [Bluez-devel] patch for d-bus support in hcid) Stephen Crane
2003-06-24 17:31     ` Max Krasnyansky
2003-06-25  9:17       ` Stephen Crane
2003-06-25 12:15       ` Marcel Holtmann
2003-06-26 17:15         ` Max Krasnyansky [this message]
2003-07-23  8:12       ` Paul Hedderly
2003-06-24  9:28 ` [Bluez-devel] patch for d-bus support in hcid David Woodhouse
2003-06-24  9:31   ` Philip Blundell
2003-09-04 21:18 ` David Woodhouse
2003-09-04 22:33   ` Philip Blundell
  -- strict thread matches above, loose matches on Subject: below --
2003-07-01  0:03 Version 3 libs/utils Max Krasnyansky
2003-07-02  1:01 ` [Bluez-devel] " Marcel Holtmann
2003-07-02  8:34   ` Stephen Crane
2003-07-02 16:29     ` [Bluez-devel] " Marcel Holtmann
2003-07-18  0:19       ` Max Krasnyansky
2003-07-18  0:10     ` Max Krasnyansky
2003-07-18  0:00   ` Max Krasnyansky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5.1.0.14.2.20030626094614.0dadee68@unixmail.qualcomm.com \
    --to=maxk@qualcomm.com \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=marcel@rvs.uni-bielefeld.de \
    --cc=pb@nexus.co.uk \
    --cc=steve.crane@rococosoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox