naive question ...

Tim Rue 3seasdbus at threeseas.net
Wed Apr 28 10:19:37 EST 2004


Quoting Tako Schotanus <quintesse at palacio-cristal.com>:

> Sean Middleditch wrote:
> 
> >On Tue, 2004-04-27 at 09:48, Tako Schotanus wrote:
> >
> >  
> >
> >>wouldn't it be great to just have some tiny examples which show off
> >>this feature?
> >>It should be possible to start some kind of small program which says
> >>something like "plug or un-plug a USB device" and have it output a
> >>message when this happens. Would be great for us newbies to get a feel
> >>for the system.
> >>    
> >>
> >
> >Go take a look at HAL, it does these things.
> >  
> >
> Well HAL  (http://freedesktop.org/Software/hal for those people who like 
> me were maybe wondering where it could be found) seems to be only for 
> 2.6 kernels so that's no option.
> 
> Besides the fact that I think that small example that show off how dbus 
> works should be found _here_ instead of having to look around (and look 
> _hard_!)  to find them.
> 
> It seems to be pretty hard to to just say: want to use dbus? Well just 
> take a look at <this code> to get an idea or: just insert <this code> 
> into your application as a simple starting point.
> 
> For me, I just want to control an application (either remote or not) 
> using dbus, because I think it is perfect for it, but without any 
> howtos/tutorials/examples it just takes too much time and effort while I 
> know that I could make YANP (Yet Another Non-standard Protocol) in no 
> time. The point is that I don't _want_ to make YANP, I _want_ to use 
> dbus! :-)
> 
> Please don't take this as criticism, I wouldn't mind writing a couple of 
> simple examples myself if I would only understand how everything works. 
> It's just that, while I know dbus isn't used yet by a large group of 
> people, there _must_ be somebody out there that has written code that he 
> thinks could help other people understand more how things work!
> 
> Cheers,
>  -Tako
> 



When I found out about Dbus it was from a search I did for IPC, but I thoutght
I
was pleasantly supprised.

I'm not sure now..... perhaps I was naive...

Here is what I see or thought dbus would allow.

* adding a dbus mechanism to a program,library, device, (functionality) would
be
rather simple.

* Once such a mechanism was added then a selected vocabulary set of the
program,
library, device (functionality) would be accessible (perhaps this would require
a list to be created in the functionalities source code). This would be along
the lines of all the functionality normally accessable to the user.

* this debus mechanism, the dbus library and the debus daemon would provide the
tools to access the vocabulary sets of programs, libraries and devices in such
a manner that the user could script and automate the use of the functionality
as they see fit. Perhaps even using some GUI engine (kparts???) to create their
own custom UI for their scripted automations.

* The security would simply rely on the already existing permissions settings
as
to whether or not a user could access given functionality. And this of course
would be admin/root controllable.

**** From this point it is only a simple matter of providing a skeleton dbus
mechanism for adding to programs, libraries, devices...(existing functionality)
and the need to make a list of what functionality is accessible via this added
mechanism. This way the coders who created all the various programs, libraries,
devices .... could do this work (simple enough to make it in the next
release...) and everybody could quickly begin making use of dbus and really
figuring out where to go with dbus dev.


But it seems I am naive.... as it doesn't seem to be intended to be that simple
and in fact not really intended for the end user to directly make use of.

Where did I get this idea??? perhaps teh Amiga and its use of IPC via what is
called arexx ports (though arexx doesn't need to be running - its only an added
 tool to further manipulate what happens from message point A to message point
B... --- and any language should be able to play here, like python.)


Anyways, regardless of what dbus is or is to be.... I sure would like what I
have described above. And for alot of reasons.....

-- 
Tim Rue (3seasdbus)



More information about the dbus mailing list