Hi Jeremias,
Jeremias Maerki wrote:
On 01.08.2008 18:42:43 Adrian Cumiskey wrote:
Hi all,
I have written a set of general purpose temporary file storage classes that are used by the AFP
Renderer in FOP on the Temp_AFPGOCAResources branch I am working on. I use them to temporarily
store and retrieve image files and AFP data structures to disk in a memory conservative fashion.
I have abstracted away all AFP specific functions into subclasses and am now thinking that these
base classes would prove quite useful for some other temporary storage needs and was wondering where
they might best reside.
I think it should probably best go in commons-io, but it is maybe a little high level for there and
would impose an additional dependency on FOP
How so?
From my understanding, when providing a release of FOP we would need to provide a properly release
versioned commons-io jar (as apposed to just svn), so there would be a dependency on commons-io
being released containing the additional code prior to or at the same time as FOP.
I'd also maybe need to request some karma to commit
them to the project.
Well, you'd need to make a proposal there before you could commit it.
Karma is the second step IMO.
Agreed.
I'm also thinking it would seem a little wrong for them to go in
xmlgraphics-commons as the work has nothing to do with images/fonts or output formats.
So why did you commit it anyway? Without giving everyone a chance to
react first?
Yes I could have left it a little longer but I hadn't received any responses back, so I assumed
(wrongly) that most people didn't have a strong opinion on the matter. I wanted to resolve this
decision swiftly so I would be able to crack on with the branch work. Now that you have raised an
objection I will of course simply place it in my FOP branch for now and we can worry about where it
should go later.
So far, I've only moved stuff to XGC which was clearly destined to be
shared between Batik and FOP or which was dependent on those shared components.
I think FileStore and its associated classes could prove quite useful for other components which
wish to save memory by temporarily saving data to file and then retrieving later.
Maybe I should just place them in FOP for now? I would be interested to hear your suggestions on
where you think they should live.
IMO, FOP is the right place for now. Probably even under the AFP package.
ATM, I can't see too much of another use case for it. I'm writing to a
temporary file in the PostScript renderer, too, but I don't see how your
code would help me there (as an example). The code can always be
moved to a different place if new use cases pop up.
Hopefully you'll see when I commit the latest stuff in the AFP branch that the FileStore class can
be easily extended and used to temporarily store different types of data. Other developers probably
won't come across this set of classes if I hide them deeply in the org.apache.fop.render.afp, and
they might spend time creating their own similar implementation. These classes have no real
dependencies on FOP or AFP and could be used anywhere.
Maybe in the case of the Postscript renderer it wouldn't make sense to use the new classes as the
existing code is written in a very postscript output specific way and is quite closely coupled
together and it would take some time to change.
Related to that, I've been thinking about setting up a Wiki page for
Apache Commons IO that lists IO-related classes and packages in other
Apache projects so that candidates for a move to common-io can easily be
identified.
Sounds like a fine idea, I look forward to seeing that :).
Adrian.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
