Sorry I forgot to reply-to-all.
---------- Forwarded message ----------
From: Salvatore Benedetto <email@example.com >
Date: Mar 16, 2007 9:34 AM
Subject: Re: [Gaim-devel] SoC gaim-vv comments (was Re: gaim-vv support)
To: Peter Lawler <firstname.lastname@example.org>
I'll throw my 2c in right at this point regarding what I suspect will be
a multitude of gaim-vv SoC proposals, and will leave further comment to
Please be aware it's been a while since I tried to do any gaim
voice/video work, so I may be slightly off the mark here. After a brief
conversation in #gaim this morning my time with one or two gaim dev's
would indicate to me that not much has happened due to a concentration
in other gaim areas and thus I suspect these points would still be valid.
Things gaim-vv needs/would-like/etc. in gaim itself to be of any major
use, in no particular order.
1. Privacy rewrite.
There's no way in the privacy API to block eg. webcam view requests.
Each request would have to be permitted/denied on an individual basis.
Similar problems would exist for listening to voice, etc. An examination
of all 'vv capable' native clients for which gaim has a protocol plugin
needs to take place and any native privacy/security features should be
available in a gaim privacy API/UI, or at minimum be easily extendable
to take such privacy considerations into account.
2. UI neutral.
Gaim-vv was dependant on GTK. This should not be so. In the spirit of
libgaim, gaim-vv should not require a specific toolkit to work. eg,
gaim-text utilising libaa for webcam viewing would be pretty neat. This
would be implemented as, for example, 'libgaimedia' or similarly funky name.
It's been claimed in the past that moving gaim to GObjects may make the
entire process easier. Whether or not this is true, I'm unable to
categorically confirm or deny. That there's still an occasional GObject
discussion would lead one to suggest that the amount of work required
implementing vv functionality with points 1 and 2 in mind, should not be
attempted until such time as a GObject'ifying decision is reached.
A decent period of time has passed from when the -vv tree was abandoned
in favour of effort on the status rewrite and the UI/core split, I still
feel that these are still the major sticking points. Personally, I'd
like to see the SoC 2007 gaim efforts focused on getting gaim2 properly
released. I think we've waited long enough. We can then move to
concentrating efforts on gaim3, where it's more likely to get the
nightmare that is a viable multi-protocol -vv API implemented ;)
Salvatore Benedetto wrote:
> The most wanted feature! :)
> Few simple question..
> What's the status of the project?
> Why did the vv project died? Was it only due to a lack of time of devs?
> Was there any other reason?
> Someone in the channels said that the lack of a media framework
> was a problem too.
> What about a libgaim-v4l library that handles all of V4L (and V4L2 )
> Compression included by using libjpeg (or libj2k).
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Gaim-devel mailing list