xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Temporary File Storage
Date Mon, 04 Aug 2008 11:29:04 GMT
On 04.08.2008 12:30:17 Adrian Cumiskey wrote:
> 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.

Oh right, I sort of read your text in a way that commons-io would have
a dependency on FOP which doesn't make any sense. But you're right, we'd
have to use a released commons-io JAR in our releases. Still, that
doesn't stop us from going down that route if it makes sense and
commons-io as a whole profits from a contribution.

> >> 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.

Thanks. When in doubt let it run 72 hours which is the normal period to
allow everyone a chance (independent of time zones, weekend absences etc.).

> > 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.

I did have a short glance at the files you've committed. I see what
you're saying. Still, I have yet to find a use case where I would see a
benefit to using your additional classes over just using plain
File.createTempFile(), an Input/OutputStream and File.delete(). Time
will show...

BTW, nothing stops you from making a proposal in commons-io anyway. That
way you could force some additional feedback.

> 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.



Jeremias Maerki


---------------------------------------------------------------------
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


Mime
View raw message