xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cumiskey <adrian.cumis...@gmail.com>
Subject Re: Temporary File Storage
Date Mon, 04 Aug 2008 10:30:17 GMT
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
>> 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
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.


>>  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
decision swiftly so I would be able to crack on with the branch work.  Now that you have raised
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
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
be easily extended and used to temporarily store different types of data.  Other developers
won't come across this set of classes if I hide them deeply in the org.apache.fop.render.afp,
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 :).


Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message