> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED] > <snip /> > The borderline cases may be very much in the minority (and must be, > judging by the degree of usage that FOP gets now) but they must be taken > into account in the design of the solution. If we go for the > low-hanging fruit and then discover that the ladder is too short we end > up back in the workshop. >
I understand, but what I'm referring to is (taking your analogy a bit further): You want an 'extensible' ladder which you can keep short for the low-hanging fruit, and extend to reach the higher ones. If you get to a tiny tree with a huge ladder, you're going to be cursing yourself anyway as your big ladder will make the job more difficult, IYKWIM (--you might not even need that ladder, but still you carried it all the way down there...). The point that would concern me is an API that forces the most trivial and common cases into a processing-model that is actually meant to accommodate rather complicated structures. So you'd end up having an overhead in 95% of the cases, overhead which strictly speaking is meant to occur in only 5% of the possible situations. If it results in (virtually) no overhead at all, this point of course dissolves totally... the ladder is then extensible in just the right way. > > I wasn't thinking of the buffers. The re-usability of the buffers is > only relevant to static-content and markers, so I don't see that as a > major issue, and would expect to keep the static-content buffers for a > page in memory for the life of the page-sequence. Markers are a bit > more problematical, and may well benefit from some "transparent" > serialization. > Sorry, I'm still a bit misguided, it seems. This part, I already got, but... > I was thinking more of the "historical" parts of the FO and Area trees. ... putting quotes around there is to beg the question, so, would that be the parts that have already been processed in some way? > At one stage I considered linking all nodes in the FO tree with > reference objects, but I was concerned about the extra layer of > reference objects and their impact on memory and performance. However, > when we get parallel FO tree, Area tree and rendering working it may pay > dividends. > > I find the language of the java.lang.ref package confusing, but I think > that phantom references open the possibility of performing serialization > "on demand", when the object is queued for GC. > Can you elaborate a bit on this? AFAICT, the actual referent of a phantom reference is itself unreachable through the reference object (the ref's get() method always returns null), so you could indeed test via isEnqueued() whether or not the referent of a phantom reference is queued for GC, and then...? A soft reference at least would allow to get() the object and do something with it or make it do something with itself before actually clearing the ref. Cheers, Andreas
