← Back to team overview

calibre-devs team mailing list archive

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