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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
