Reading this, I have the impression, that the MICR/OCR modules contribute a significant but not a major part to the overall applications functionality? I further assume that they make only a relatively small part of the projects total size (e.g. some kB MICR*.pm + some MB for bitmaps, configs, templates, etc.)?

If this is true, the application should deserve its own project site and the MICR module its slot at CPAN. It doesn't make sense that an overwhelmingly large part of the project deals with just demonstrating the functionality of a single module. That would also degrade your application to just a demo - which it doesn't seem to be. On the other side, most people downloading your module might not be interested in the very specific functionality, the application offers.

So the question is where to draw the line between module (CPAN) and application (project site)?
It is a litmus test for a modules usefulness, that it can demonstrate its capabilities with a relatively short amount of demo code. If you cannot come up with a small demo program, the module might not be fit for the given purpose, yet. The demo is not supposed to do something useful - it's aim is to educate. A potential demo candidate might be found among the CLI tools.
If bitmaps are part of the module, e.g. for calibration purpose, put them into the modules package, but make it as small as possible in order to focus on the very specific functionality the module promises to deliver. A link in the modules documentation can point to your projects site, where you can keep CLI tools and the web based application for those interested in more than the module or those who want to see the modules usage in a bigger application.

Splitting application and module(s) might have the additional advantage, that you can concentrate on the application and don't have to update the CPAN any time, you have added a new feature to your application which doesn't fit into a module. I would expect, that the application provides more opportunities for development (changes at a higher rate) than the module after it has stabilised. Although beta/preview-versions of the module could be made available at the project site first, increasing quality and stability of the module uploaded to CPAN. The application site comes handy too if you develop another application based on the same module or if you want to provide some megabytes of OCRs for demo- and test-purpose.

Just some thoughts, ...

In reply to Re: How to distribute complex perl based app by Perlbotics
in thread How to distribute complex perl based app by leocharre

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.