> Might be. > You still increase the number of watched resources and potentially > a lot.
In the worst case, maybe. But I think the worst case is rather pathological: many distant leaf monitors with / as their pair-wise common ancestor. > This really can have a large impact and it's very hard to assess > how many things will break. Things do break on changes, no matter if > this is right or wrong to do the change, and gamin potentially affects > a lot of desktop applications and expected user behaviour. Adding monitors > to the full hierarchy is taking a lot of risks IMHO. It sounds to me like there is something more you wan to say here. Otherwise it seems to me anything that self-describes as a rewrite is high risk. > My view about this is "Open Source is a process", that process means to > operate as a team, in an open fashion, and pushing big changes like the > recursive monitoring should never be done silently. If you do so, you break > the knowledge of every other people in that team, reducing the value of the > code in the end, even if intrinsically the code may be better after that. I tried to summarize the changes this patch introduces in the mail accompanying the patch. Of course, it is only summary and I encourage you to study the patch. > > The debugging API exposes implementation details. If the > > Those implementation details are crucially important. If I get a Changed > even because I watched using dnotify versus because watching with poll it > is very different, this may meen the busy detection code in the server just > failed. I also want to monitor that there is no leak of kernel monitors > from the regression tests because that means leaks of filedescriptors and > potentially filling hard drives with unreachables but still open files. I'm rather confused. It makes sense that the implementation is sound and that we should somehow check that. I don't see why exposing the implementation details are crucially important. It seems like documentation: documentation which is far away from the code is rarely updated which is, I think, why you use a documentation extractor. It seems the same logic applies to implementation assertions. _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
