[parted-devel] History patchset

Matt Davis mattdavis9 at gmail.com
Wed Feb 20 03:44:28 UTC 2008


On Feb 15, 2008 6:17 AM, Jim Meyering <jim at meyering.net> wrote:
> Otavio Salvador <otavio at debian.org> wrote:
> > Anant Narayanan <anant at kix.in> 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



More information about the parted-devel mailing list