calibre-devs team mailing list archive
-
calibre-devs team
-
Mailing list archive
-
Message #00111
Re: Modularization: The Empire Strikes Back!
On Saturday 07 February 2009 10:46:43 Marshall T. Vandegrift wrote:
> On Sat, Feb 7, 2009 at 1:21 PM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:
> > command subcommand
> >
> > is really only needed if the subcommands do widely different things
> > from each other. Since we're trying to keep the Readers/Writers as
> > simple as possible, they should ideally have only a few options that
> > will not change their behavior too much.
>
> I was thinking that it would make it easier to introduce new pipelines
> with a custom set of transforms. If transform plugins can only be
> slotted into all conversion pipelines, I'm not sure how you're planning
> on dealing with plugins which are appropriate for some conversions, but
> not others.
>
Yeah but then we'd end up with an unusable commandline like the ones for the
various video encoders. The transforms plugins will be controlled from three
sources
1) Input format plugins will be able to specify which transforms must be
applied, alongwith default values for whatever options the transforms support
2) Output format plugins will specify which transforms must be applied,
alongwith default values for the options the transforms support
3) The user can turn on and off some optional transforms via simple boolean
options. The user can also customize the behavior of the transforms to be
applied via commandline options that the transforms will add to the option
parser.
I'm leaning towards a user interface that has as few options as possible. I
don't think it will be very useful to allow the user to customize the
conversion pipeline. Is there an actual use case for this? Instead, the way I
envision it is that the input and output plugins will know what transforms
they need. In addition ebook-convert will insert some common transforms into
the middle of the pipeline.
The user will be allowed to customize the behavior of all these transforms,
including in some cases turning them off. There may be some transforms that
start in a default off state and the user can turn them on. The user will not
however be able to change what transforms are put into the pipeline as that
way lies interface chaos.
So this is what the pipeline will look like:
1 -- 2 -- 3 -- 4 -- 5
Where:
1) Input format plugin
2) Transforms specified by input format plugin
3) Common transforms for all pipelines
4) Transforms by output plugin
5) output plugin
Each of these stages (including 1 and 5) will be able to add options to the
command line.
Now coming to the user interface:
I am leaning towards a modular help system somewhat like sub-commands but
without the actual sub commands. So:
ebook-convert -h
basic usage message
ebook-convert input.type output.type -h
help message for this particular pipeline.
Basically ebook-convert input.type output.type is like a something2something
command
I think that addresses your issues?
Kovid.
References