You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Adrian Cumiskey <ad...@gmail.com> on 2008/08/01 18:42:43 UTC
Temporary File Storage
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 I'd also maybe need to request some karma to commit
them to the project. 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.
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.
Adrian.
---------------------------------------------------------------------
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
Re: Temporary File Storage
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Temporary File Storage
Posted by Adrian Cumiskey <ad...@gmail.com>.
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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Temporary File Storage
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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?
> 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?
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.
> 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.
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.
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