Hi Richi,
> > > Correct, but I think what Mickey is after is that the client programs just
> > > ask for "contacts" and the translation layer checks both
> > > '/org/openmoko/contacts' and '/org/gnome/evolution/dataserver/addressbook'
> > > and anywhere else contacts or an addressbook may be. Per
Hi Jim,
> Okay so there has been a fair amount of discussion here but I think
> we've veered off track a bit. To try to re-phrase my thoughts:
>
>- Current DBus object paths are application-centric (this is by
> choice of the application)
the object paths are specific to the daemon (I pre
Hi Kalle,
> >- Current DBus object paths are application-centric (this is by
> > choice of the application)
> > [..snip..]
> >- There seem to be two options (ignoring the uninteresting ones):
> > - take a combination of the existing application-centric paths and
> > make it availab
Hi Kalle,
> > You are still missing the big picture here. Every OpenMoko specific
> > interface is a step back. You will have OpenMoko specific things,
> > because that is unavoidable since some stuff depends on the actual
> > hardware and can't be generalized. For all other things you wanna go a
Hi Jim,
> > You have to understand that the object path is not the unique element in
> > the D-Bus architecture.
> >
> Yep I understand this bit and that's why I think abstracting the paths
> works. Say you have three separate items that provide address
> information on the paths:
>
> /org/
Hi Kalle,
> > the question is still why. We have EDS. So no reason to invent another
> > interface for the same purpose. Don't try to over-complicate things.
>
> I'm not saying that there should be any change to dbus as it is. I'm
> only advocating the 'well-known' part of this all.
nobody was t
Hi Christopher,
> > And again. Nobody is going to change D-Bus. It works like it does, but
> > you need to understand how it works.
>
> Newbie to Dbus question: any suggestions for a good place to get started on
> gaining that understanding?
the best advice is to start using it and play with it
Hi Richi,
> > You do know that the object path is specific to the daemon that provides
> > it anyway. The access to a method or signal of an interface is done via
> > the unique bus name _and_ the object path.
> >
> > This means that daemon A can register /org/foo and daemon B can
> > register /o
Hi Richi,
> > > Personally I would prefer
> > >
> > > bluetooth.SetMode(bluetooth.Mode.CONNECTABLE) # or whatever the
> > > consensus is for constants
> >
> > Except that D-Bus is not C# or Java. It is an object oriented approach
> > for an API, but it is not an object oriented programming langu
Hi Gustavo,
> I'm trying to find how to get Linux interoperate with bluetooth
> phones, both to connect to headsets (useful for openmoko) and
> telephones connect to linux and use it as headset (maybe useful for
> openmoko).
>
> The first case, connecting to headsets, can be done using btsco, not
10 matches
Mail list logo
