Quoting meta@xxxxxxxxx, on Mon, Jul 11, 2005 at 11:14:54PM -0500:
> Sam Roberts wrote:
>
> >The most annoying thing I find with the RSS encoder is failures seem to
> >return nil. No exception, no error message, you call a method, get nil
> >back, and then have to start reading the code, and thats not so easy
> >because many of the methods don't actually exist in text form, they are
> >created on the fly.
> >
> >
>
> Well, I have to say that having spent some hours working my way through
> it, I don't like the RSS library as a decoder of RSS. It seems to be a
> literal translation of the standards into code, rather than something
> designed to be easy and convenient to use. As a result, you need to know
I think thats a good design - start with a solid implementation of the
data structures, add easy and convenient APIs on top. Some work was
started with the RSS::Maker API, which I like a lot, and stole the
design for my vCard encoding API.
But... the encoding API just returns nil instead of raising descriptive
exceptions when something is wrong. Thats not a reason to start from
scratch, it just needs better error reporting!
On the decoding side, it seems to be completely missing an easy to use
API. Oops.
I've sympathy with the author, I've had similar problems, many people's
idea of easy is "does what i want to do", but how is he to know what you
or I want to do? And what if the thing I want to do is only possible
in some forms of RSS, or is based on an assumption about RSS that isn't
true, or is only true for some versions?
> what kind of RSS feed you're parsing, because the API for accessing the
> parsed objects is different depending on the input format--your code may
> work fine for RSS2.0, and then fall over with a nil when fed RSS1.0 by
> the next feed.
One problem may be that what is in 1.0 just isn't in 2.0 in an obvious
way, so to present them as the same when they inherently are fairly
different involves making application-specific assumptions.
That said, maybe the API just isn't there yet, and he hasn't had the
time to write it (life occaisonally gets in the way of full time coding
for free). But..
> I try to avoid wheel-reinvention, but this particular wheel is just
> begging for it...
maybe you could contribute a nice high-level decoding API, so rather
than reinvention a wheel, you contribute a comfortably padded
gyro-stabilized unicycle to fit onto the existing wheel!
Cheers,
Sam
--
Above all, remember that it is not profitable to immerse yourself in a
consideration of the pros and cons to a point where you do nothing but
vacillate between conflicting decisions. You will learn, even from mistakes.
- Bee Keeping for Profit and Pleasure, 1943
|
