Re: [gamin] Re: Runtime selectable backends for Gamin [u]



On Wed, 2004-08-25 at 21:34, Daniel Veillard wrote:
> On Wed, Aug 25, 2004 at 09:22:57PM +0200, Martin Schlemmer [c] wrote:
> > > > the code is using dnotify and polling at the same time now, so it's
> > > > more complex than what your patch suggests.
> > > > 
> > > 
> > > I should admit that it is not the most elegant solution, and will
> > > not scale if more backends are used (will there be much more added
> > > or in pipe-line to be added?).  I however wanted an easy way to
> > > integrate both dnotify and inotify support without recompiling,
> > > and currently it seems to be working fine with dnotify - having a
> > > bit of issues getting inotify working with devicemapper ...
> > > 
> > > I however do not see concern with dnotify also using polling, and
> > > would appreciate enlightenment.
> > > 
> > 
> > If possible I would still appreciate points against proposed patch
> > (except that it will not apply anymore against cvs :).  If it is the
> 
>   Well can you fix it to work against CVS then ? Or at least 0.0.7
> 
> > implementation - I am open to suggestions.
> > 
> > Basically we check each backend in order of preferrence (inotify first,
> > as it is a configure option for now), and if it cannot init it, it
> > falls through to the next, instead of just checking one.  I am not
> > sure how to handle future ones - there might be need for a more
> > flexible solution as to what order the backends should be checked,
> > or maybe which one first.  Or somehow through gconf?
> 
>   In general your patch is about using A vs using B vs. using C, and now
> B and C work together and possible A and C too. I just want this to be very 
> clear and if you start patching this kind of code you must check you
> don't break getting B and C working at the same time.
> 

Well, in theory only one should be initialized (Or in the case of B,
C as well, but that will be done by B), and as long as an init function
do not leave strings unattached, I do not think there will be any
issues?

> > Anyhow, if its implementation that bothers, what about attached patch?
> 
>   Applied, thanks
> 
> gam_server.c: In function `gam_init_subscriptions':
> gam_server.c:75: warning: suggest parentheses around assignment used as truth value
> gam_server.c:80: warning: suggest parentheses around assignment used as truth value
> 
>   please fully parenthesize all boolean expressions in the future please.
> I removed ret, it was useless.
> 

Ok, thanks.

> > (I am not sure if you would want to use gam_backend_remove_all_for in
> > a global instance later on?)
> 
>   I'm not sure I fully understand could you be more explicit ?
> 

Basically will gam_inotify_remove_all_for (or gam_poll_remove_all_for
for that matter) ever be used in global contect to warrant
gam_backend_remove_all_for ?


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]