On Feb 15, 2008 6:17 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Otavio Salvador <[EMAIL PROTECTED]> wrote: > > Anant Narayanan <[EMAIL PROTECTED]> writes: > >> On 13-Feb-08, at 4:59 PM, Jim Meyering wrote: > >>> A new feature like this must not introduce incompatible API changes. > >>> Whether that's feasible, I don't know, off hand. > >> > >> We could include history support in libparted-2.0. API may change in > >> other areas as well? > > > > I think that Jim means we can't change, radically, how libparted works > > otherwise the effort need to migrate to it will be too big and noone > > will do that. > > Sort of. > The point is that if there is to be a change, > it has to be for more than a "would be nice" new feature. > > And if many public function signatures require modification to > support a feature that some applications won't even want to use, > then maybe it's not such a desirable feature after all. > > However, if developers of important libparted client applications > say they want this feature and are willing to do the work required > to adapt their code to use it, then it's probably worthwhile.
Jim, et all I took another peek. It should not be too much work to roll this history change into parted and out from the library. Unfortunately that would require a global instance of a history manager, as I cannot bind a manager pointer in with any other library structures, such as the PedDevice which previously contained a pointer to the history manager. I do not want to muck with the command callback routines (do_<xxxxx>), so a global singleton seems the most logical. If that is cool I will continue in that direction. I only want to implement this if it will be deemed useful. I believe it is useful, but I value the opinion of yourself and the rest of the parted team over my opinion. -Matt _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
