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
Marcel Holtmann wrote:
[...]
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)
- Without a well-known set of paths
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
ti, 2007-01-30 kello 10:58 +, Jim McDonald kirjoitti:
>- 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-ce
ti, 2007-01-30 kello 12:27 +0100, Marcel Holtmann kirjoitti:
> 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 general
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
Marcel Holtmann wrote:
[...]
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:
/o
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/
Marcel Holtmann wrote:
[...]
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.
So this is an argument against abstraction, which I understand but
disagree with. It comes back to the two choices that I
Hi marcel,
> 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.
I'm saying that it's
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
On Tuesday 30 January 2007 05:03, Marcel Holtmann scribbled in crayon on the
back of a kid's menu:
> 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 t
> Therefore it'd require a lot of standardisation to create such a thing
> where these all would be just another device of type X. If this was
> possible then we *could* have a dbus address that has a program that
> could advertise these features. Like this:
>
> /xx/yy/zz NETWORKING_FEATURE
> /xx
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
On Tue, 30 Jan 2007, Marcel Holtmann wrote:
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
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
18 matches
Mail list logo
