[Rsslibj-developer] suggested modifications

[Joe S. <acr...@io...>]

i'm never any good with CVS and patch, so i'll leave this to someone
else to do, but here goes.

most of what I'd be doing would be loading an rss file, adding stuff to
it, and saving it again.  To do this, I would want to make sure to save
it in the same format, and add it following typical "blog" format
(most-recent-first).

1) if RSSReader is used to load an RSS file, it or the Channel it
produces should remember what format (092, rdf, 200) was used in the
original file in order to save it to the same state.  A default
getFeed() would do it automatically, or "rss =
channel.getFeed(channel.getOriginalFormatType());".  I realize, of
course, that this requires a default value to be selected for when
Channel was constructed in user code instead of RSSReader, and the
selection of one standard as the default will annoy those who prefer the
other (aren't holy wars fun?).

2) in addition to addItem() (which, using the List interface does an
append), there should be an insertItem that adds it to the front,
following normal RSS for blog standards.  Right now that can be done by
doing "getItems().add(0, new Item(...))", but to me that's risky.  From
a public API perspective, its rare for exported Lists and/or Collections
to actually be the contained object, rather a copy (perhaps even a copy
with synchronized or unmodifiable tagged to it).  There's the issue of
"messing with the Channel's internals" that I don't like about it, even
if it is safe in this instance because we have the source code to see
that it is.

Its not safe in most of the JDK's instances (java.awt.dnd,
java.security.cert, javax.imageio), so users following Java's own
practices may not be used to doing that. For example, if one were to
modify the List returned in SpinnerListModel, no event would be fired
and the data in the model would be out of synch with the spinner.  The
javadocs don't tell you this, one has to infer it from the phrase "Note
that list is not copied, the model just stores a reference to it",
actually found in setList(), not getList(). Interfaces like that tend to
make the experienced Java developer more cautious about modifying
collections returned by objects.  Its easily seen as a violation of
encapsulation.

Joe