hugin-devs team mailing list archive

[Yuv <789442@xxxxxxxxxxxxxxxxxx>]

Rule has been discussed and is now published with the Coding Style Guide

http://hugin.sourceforge.net/community/coding_style/

** Changed in: hugin
       Status: New => Fix Committed

-- 
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:
  Fix Committed

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.