[Utopia] Re: [patch] one-to-many HAL integration
- From: "John (J5) Palmieri" <johnp redhat com>
- To: Sriram Ramkrishna <sri aracnet com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, dave novell com, utopia-list gnome org, Alexander Larsson <alexl redhat com>
- Subject: [Utopia] Re: [patch] one-to-many HAL integration
- Date: Fri, 13 Aug 2004 13:46:35 -0400
On Fri, 2004-08-13 at 08:47 -0700, Sriram Ramkrishna wrote:
> On Fri, Aug 13, 2004 at 11:48:12AM +0200, Alexander Larsson wrote:
> > On Thu, 2004-08-12 at 22:17, Sriram Ramkrishna wrote:
> > > On Thu, Aug 12, 2004 at 09:08:36AM +0200, Alexander Larsson wrote:
> > > > Also, the gnome-vfs-volume-ops.c parts means we have to link gnome-vfs
> > > > to libhal. I had hoped we could keep that dependency to the vfs daemon,
> > > > to decrease the number of libraries every app links to. (especially the
> > > > number of unstable libs.)
> > >
> > > I agree that reducing dependicies is a godo thing, but wouldn't
> > > that require some code movement to do that? If so, I have something
> > > related.
> >
> > Why? We already only use HAL from the daemon, not from the lib.
>
> Ah.
>
> > > I'm trying to write my iriver driver which is not based on the
> > > usb mass storage driver but I have to communicate with the iriver
> > > mp3 player using USB commands. But I want to be able to have the
> > > gnome-vfs daemon detect that the iriver is plugged in through HAL.
> >
> > Yes, long term this is something i want to do. Extend the module API
> > with something you can load into the gnome-vfs daemon to look for plug
> > in/out of some hardware device the kernel doesn't handle, then use that
> > to create GnomeVFSVolumes with a uri to the method that allows you to
> > access the device. [I.E. the uri has to be of the form something like
> > method://<device>/<path>, and not just method:///<path>, so we can
> > handle multiple devices etc]
>
> Great! In the meantime I will suppose I will just write the driver
> itself and not worry about HAL for now.
In reference to your iRiver driver why not just write a generic library
like libgphoto but for music playback devices? This way we can unify
all block audio devices and devices which have their own access layer
under one audio:// method?
--
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]