On Mon, Apr 30, 2012 at 8:16 AM, Andrea Aime
<[email protected]>wrote:
> On Mon, Apr 30, 2012 at 3:34 PM, David Winslow <[email protected]>wrote:
>
>> Not to hijack the catalog discussion, but I will have some time later
>> this week to work on implementing an output mode for the WMS
>> GetCapabilities response to have it omit errant layers instead of
>> generating invalid XML. If you have more detailed thoughts on
>> "transactional" XML encoding I am interested to hear them. (The rough
>> idea, buffer starting with an open tag until a closing tag is encoded, is
>> pretty straightforward but I am not very familiar with the APIs and
>> implementations involved.)
>
>
> Let me see, I had in mind two ideas to make the usual TransformerBase
> subclass handle "transactional" writes,
> one based on command recording, the other based on output stream buffering.
>
> The first one basically is based on the observation that the code going
> through TransformerBase basically
> writes XML via a handful of methods, start/end/chars/cdata, so one may put
> the code in "recording mode"
> and just record the calls to those methods but not make them act on the
> ContentHandler,
> see if we can encode stuff, and on "commit" replay those against
> the actual contentHandler, otherwise throw away the list of recorded
> commands on "rollback".
>
> A lower level approach is based on the idea that regardless of what you do
> you go through a OutputStream,
> so one could create a wrapper that can switch between stream and in memory
> buffer mode, put it
> in buffer mode before starting to write a layer, write it, in case of
> success write the buffer contents to the
> actual stream, in case of failure just throw away and move on.
> This seems simpler and may have a smaller footprint, at the same time we
> have a few levels of abstraction
> in between so we may not be 100% sure of what the layers above are doing,
> which might result in
> switching to buffer mode and receiving some content that we though we
> should have already written
> out after the switch (which would happen if anything above the output
> stream does some of its own buffering).
>
> Agree with andrea on the tradeoffs between approaches. The stream approach
would be simpler but if i remember correctly the underlying is abstracted
away to the point where you don't really have access to it. Could be wrong
though, haven't dealt with that api in quite some time.
>From an api standpoint what I had in mind was this, consider the current
(reduced) example of writing out a layer:
start("Layer");
element("Title", serviceInfo.getTitle());
element("Abstract", serviceInfo.getAbstract());
...
end("layer);
I thought an approach similar to java.io.InputStream.mark() could be used.
So it would look like:
//create a "savepoint"
mark();
try {
start("Layer");
element("Title", serviceInfo.getTitle());
element("Abstract", serviceInfo.getAbstract());
...
end("Layer");
//all good, commit
commit();
}
catch(Exception t) {
//error, rollback to savepoint
reset();
}
$0.02
Cheers
> Andrea
>
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
