hugin-devs team mailing list archive

[Yuv <789442@xxxxxxxxxxxxxxxxxx>]

More Thoughts

> > The main trade-off will be between bloat and functionality, and indeed
> > this thread and Thomas' "we don't need" statement is a taste of things
> > to come.
> 
> Scripts are really lightweight. If you look at woa, which is really a
> large script, it's merely 59K. The real load currently is the hsi
> module, _hsi.so, weighing in at 8.1M. I wouldn't worry about bloat
> from scripts.

actually I do not worry about bloat in terms of disk space or bandwidth.
I worry about bloat in terms of namespace / quantity of scripts.
Example:  there can be a gazillion of scripts to generate an initial pto
with the input images distributed according to a pre-determined shooting
pattern (a feature request that has come up fairly often).  One can have
a script that does stacks, another a script that shoots left to right;
another is optimized for fisheyes (the typical 6+Z+N), etc.  how many
such scripts do we want to include with the core Hugin? and how many
more will there be in the online script repository?


> And if you worry about bloat, defining a clean API for
> hugin, so that hsi can wrap what's really needed - and wanted - to be
> accessible by everyone instead of near enough everything declared in a
> bunch of headers never meant for the wider public. I'd estimate
> _hsi.so could shrink to a quarter or so.
> 
> A proper API specification would also be a remedy against scripts
> breaking as soon as the headers in question are modified in an
> incompatible way

The biggest advantage I see in a carefully crafted clean API is human:
the more understandable and simple the API, the more users it will
attract.

Stability of the API to prevent script breaking is an extra bonus, but
IMHO it is not extremely critical.  Forcing backward compatibility would
only hinder progress and I'd rather deal with breaking scripts than with
a rigid structure.

I would propose that we adopt a rule:  scripts should be written against
the API that is frozen in a release (e.g. 2011.2, 2011.4, 2012.0, ...).
Everything else is at risk of breaking any time and users of the
bleeding edge should expect to experience such errors.

There will still be an extra burden: with every release all scripts will
need testing and eventually update.  This has positive sides as well:
it will prune the body of scripts from scripts that have been
supreseeded.


> - and that's quickly done: change a call signature or
> type name and swig will duly wrap it to keep the module consistent
> with the C++ code, and hsi code using the old names/signatures breaks
> and has to be adapted. Resulting in lots of frustrated users and
> script-writers (and support load: 'xyz.py does not work any more' -
> 'are you using hsi 5886.X already?' ...)

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/789442

Title:
  2011.2: formalize API/headers immutability

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  In the words of Kay:
  > Scripts are really lightweight. If you look at woa, which is really a
  > large script, it's merely 59K. The real load currently is the hsi
  > module, _hsi.so, weighing in at 8.1M. I wouldn't worry about bloat
  > from scripts. And if you worry about bloat, defining a clean API for
  > hugin, so that hsi can wrap what's really needed - and wanted - to be
  > accessible by everyone instead of near enough everything declared in a
  > bunch of headers never meant for the wider public. I'd estimate
  > _hsi.so could shrink to a quarter or so.
  >
  > A proper API specification would also be a remedy against scripts
  > breaking as soon as the headers in question are modified in an
  > incompatible way - and that's quickly done: change a call signature or
  > type name and swig will duly wrap it to keep the module consistent
  > with the C++ code, and hsi code using the old names/signatures breaks
  > and has to be adapted. Resulting in lots of frustrated users and
  > script-writers (and support load: 'xyz.py does not work any more' -
  > 'are you using hsi 5886.X already?' ...)

  Currently the Python wrapper is
  a) bloated and
  b) very fragile.

  The negative consequences from (a) are an API that is complex  and not
  as user-friendly as it could be.  I am not worried about the extra 8M
  disk space or download-bandwidth.

  The negative consequences from (b) are far worse.  As described above,
  a small change in the wrapped headers can lead to incompatibilities
  between the hsi module and the body of scripts available.

  One potential solution is to "guarantee" (best effort) a stable API
  only on releases (odd version numbers) of Hugin.  This means that
  users on the bleeding edge may experience the occasional frustration;
  and that with every release the whole body of plug ins would need to
  be tested against that release to determine if the API breaks or not.

  The cleaner solution to both (a) and (b) is to define a fine grained,
  clean, lean and streamlined API, but I am afraid that the task is way
  too big for a  release and is better left for a major project, e.g. a
  Google Summer of Code project.