SoC2007 project Panotools Architecture

From PanoTools.org Wiki
Revision as of 14:15, 24 March 2007 by Erik Krause (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See SoC 2007 overview for usage hints and a page list.

Architectural Overhaul of Panotools

Currently PanoTools is rather like a collection of monolithic tools that you would use from the UNIX command-line, and those tools are communicated with input 'scripts' even when linked as a library.

The goal of this project is to reorganise those processes of PanoTools into smaller chunks of codes with well defined interfaces so that easier employment, extension, and maintenance will be possible in the future.


Deliverables

  1. PanoTools as a collection of functions that needs no parsing and writing of 'script' to access
    • Common tasks should have well defined function interfaces
    • Independent tasks should have accessible interfaces of their own so that they can be easily replaced independently
  2. Possible encapsulation of data
    • Well defined data representation with which the functions will be communicated
    • Possibly a structure that can be easily converted to an XML representation
  3. File I/O functionality
    • Parsing/generating of the 'script' format currently in use
    • Possibly new XML format to be added
  4. Possible Object-oriented consideration for flexible extension
    • Minimum (ideally no) modification when adding new variation of a task
    • Polymorphismic solution would be beneficial
    • Possibly by providing C++ wrapper

The new architecture should allow flexible and easy access to the various steps of panorama creation process. Identifying the separate tasks in PanoTools and defining a good interface for each of them will be the most crucial task of this project.

Also important is the data representation to be used in the interface for those functions instead of the scripts. Those representation may be designed so that new XML format can then be defined upon it to replace the conventional script files.

In addition, the design decision as to how extensible the library should be has to be decided. Easy to extend/maintain modularity does not need to be as flexible as the polymorphism in the object-orientated programming. One possibility is for the PanoTools to become an implementation simply easier to modify; a new general C++ interfaces can then be written to allow compatible implementations of PanoTools' different steps.


Timeline

  • (to be planned)


Discussion

  • Choice of license could be asked when writing new portion of codes. The PanoTools' source that has already written will certainly stay under the GPL (well, unless the authors authorise otherwise, but practically they are all under the hood GPL now and forever). However the newly written portion of the code; like the interface definitions, the new file format handling, and the possible C++ wrappers; can stay out of GPL. That would allow more flexible choice for the authors who want to write a compatible library with more relaxed license like LGPL or BSD allowing commercial use of the new implementations.
    • I'd say all in LGPL. I want to make sure those interfaces will stay opened. --Ippei 03:37, 19 March 2007 (CET)


Students planning to apply

  • Ippei UKAI (Also applying for New GUI project; the GUI is in my top priority because I care more about the ordinary users, but I'd be happy if either of those would be taken by someone else so that both will be done this summer.)
  • Come on!