Let a thousand (well, two) Tiny modules bloom

Alias on 2007-01-26T02:19:26

January should see the release of another two modules in the ::Tiny series.

After mailing the DateTime mailing list, and looking into using DateTime::LazyInit as a substitute for DateTime::Tiny, it looks like I can't modify it as I need without either violating the integrity of lazy init, or bloating beyond the 100k limit.

So it looks like DateTime::Tiny is going to go ahead.

The second Tiny module to arrive shortly, and the first one written by someone else that has met all of the criteria for the Tiny suffix, will be XML::Tiny.

As I understand it from a quick review of the code (mailed to me for nameing approval), XML::Tiny (link won't work till after uploaded) is an implementation of an XML parser that targets a specific documented "minimal xml" subset of the entire XML spec.

And all in about 30 lines of code and well less than 100k of memory.

I'm excited to see a new member of the family, and I can't wait to try it out.


What are the criteria for the "::Tiny" suffix?

jweveland on 2007-01-29T17:11:53

Just out of the idleness of curiousity, of course :-)

Re:What are the criteria for the "::Tiny" suffix?

jordan on 2007-01-29T17:18:34

I have an answer to this question, but the margin of this post is too small to contain it.

Re:What are the criteria for the "::Tiny" suffix?

Alias on 2007-02-01T06:23:15

The quick version is as follows.

1. Tiny modules provide a non-complete replacement for large modules in "as little code as possible". "Large" is loosely defined as needing multiple megabytes of memory to load the module (before doing anything).
2. They should provide enough functionality to solve a useful set of use cases.
3. A Tiny module must consist of only one .pm file.
4. A Tiny module must be pure Perl, and back-compatible to at least 5.005 (preferably 5.004)
5. A Tiny module must have no non-core dependencies, so if needed the .pm file can be dropped onto a system by hand, or embedded in other modules.
6. A Tiny module should use as little memory overhead as possible. This should be at the VERY most 10% of the large module. Ideally it should use less than 100k of memory to load.
7. While the lack of some features is acceptable, the Tiny module should endeavor to be COMPATIBLE with the larger one wherever possible (to use a similar API, etc).

That's the rough guidelines...

Re:What are the criteria for the "::Tiny" suffix?

jweveland on 2007-02-01T14:16:19

Thanks. Hmmm... let's see here...