Another config question

[Roy M. Silvernail]

Having opened my big mouth about the RSS plugin, I'm trying to sort out
the setup information storage. I think I want to use Storable, at
least initially, since there's a fair amount of stuff to store and the
prefs file would look damn ugly with cached XML in it.

So... where to store the Storable db? Is there a convention? And how to
hook the setup display routines to populate the textfields with their
current contents (as well as an expanding list of entries, ala Title
Formats)?

Bonus question: what's the consensus on underlying database storage? Are
the track database guys going to move away from Storable? Do we want to
use DBI (initially with flat files, maybe)?

Bonus question #2: how many esoteric Perl modules can I require before
Joe Average glazes over and faints? :)
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
http://www.rant-central.com is the new scytale
Never Forget: It's Only 1's and 0's!
SpamAssassin->procmail->/dev/null->bliss

[Craig Brannan]

Speaking on behalf of average joes everywhere....

I'd say 0 (zero) ;-)

Seriously - in a thread with a similar question a few weeks back, my
$0.02 was that as long as there is clear documentation at the top of
the file or in an accompanying readme, people may enjoy the adventure
of getting the new plugin to work.

Make it a reverse engineering project - and I think peoples interest
will diminish pretty quickly.

This opinion is solely representative of my personal patience (or lack)
with such things...

cb.


On Dec 9, 2003, at 2:48 PM, Roy M. Silvernail wrote:
>
>
> Bonus question #2: how many esoteric Perl modules can I require before
> Joe Average glazes over and faints? :)
> --

[Roy M. Silvernail]

On Tuesday 09 December 2003 21:47, Craig Brannan wrote:
> Speaking on behalf of average joes everywhere....
>
> I'd say 0 (zero) ;-)
>
> Seriously - in a thread with a similar question a few weeks back, my
> $0.02 was that as long as there is clear documentation at the top of
> the file or in an accompanying readme, people may enjoy the adventure
> of getting the new plugin to work.
>
> Make it a reverse engineering project - and I think peoples interest
> will diminish pretty quickly.

I was kinda afraid of that. If I steal the render code from Syndic Lite,
parsing RSS is just about bulletproof, but that will require XML::RSS and all
its prereqs. About that time, one finds out whether CPAN is set to
automatically follow dependencies, and Joe begins to sweat. If I go low rent
and regexp things, the prereqs go away, but the parsing gets fragile in the
face of feeds that aren't strictly archetypical.

I think I'll try the low-rent approach first. If it breaks badly in the hands
of consumers, I'll just go back and beef it up (and write docs).

> This opinion is solely representative of my personal patience (or lack)
> with such things...

Least ways you're honest about it. :)