RFC 16: MapScript WxS Services

http://mapserver.gis.umn.edu/development/rfc/ms-rfc-16 is the new link for the RFC

Most code now checked in, including updates to python and Java mapscript
to support the owns_data field in gdBuffer.  

Also a new Java test program (mapscript/java/examples/WxSTest.java). 

Still outstanding work to do on msio locking, and stdin handling and testing.

PHP not updated at all.  

Added Assefa to the CC since he volounteered to handle the PHP part.  ;)

Assefa,

In addition to the new items listed in the RFC (msio functions, 
and mapObj::OWSRequest()) you will also need to implement an analog of the
OWSRequest object (see mapserver/mapscript/swiginc/owsrequest.i).  

Let me know if you have any particular questions.  

Bug http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1790 has been added to
track php changes.

I updated php mapscript with most of the functionnalities.
There is a problem that I had :

  if(ctx->readWriteFunc != msIO_bufferWrite )  was always true env though the
readWriteFunc was using the msIO_bufferWrite  function. I was wondering if this
is just on windows. I disactived the test for now.

*** Bug 670 has been marked as a duplicate of this bug. ***

Greetings,

  I've compiled MapServer from the CVS HEAD 4.9-dev (2006-07-28) and I'm
suposing the msIO_getStdoutBufferBytes is not working properly when used
in Java Mapscript. I've written a very simple example to explain how it
happens. Please take a look at it :

      public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOExcept

      {
        PrintWriter p = resp.getWriter();
        mapObj map = new mapObj("/home/maps/rs.wms.map");

        OWSRequest reqOWS = new OWSRequest();
        reqOWS.setParameter("SERVICE", "WMS");
        reqOWS.setParameter("VERSION", "1.1.0");
        reqOWS.setParameter("REQUEST", "GetCapabilities");
   
        mapscript.msIO_installStdoutToBuffer();
        map.OWSDispatch(reqOWS);
   
        String contentType = mapscript.msIO_stripStdoutBufferContentType();
        byte[] content = mapscript.msIO_getStdoutBufferBytes();
        p.print(new String(content));

      }


The "byte[] content" stores the result of
msIO_stripStdoutBufferContentType and it has some garbage data at the
end. After the > 0x3E we have an NL 0x0A and finally a EOF 0x00, BUT the
content doesn't stop at this point, there are more data after the 0x00
and the Java Mapscript can "see" it. That's a big problem, because when
this "content" is returned, the resulting XML is corrupted. Please check
this example bellow.

    000018a0  20 20 20 20 20 20 20 20  20 3c 2f 4c 65 67 65 6e  |         </Legen|
    000018b0  64 55 52 4c 3e 0a 20 20  20 20 20 20 20 20 3c 2f  |dURL>.        </|
    000018c0  53 74 79 6c 65 3e 0a 20  20 20 20 3c 2f 4c 61 79  |Style>.    </Lay|
    000018d0  65 72 3e 0a 20 20 3c 2f  4c 61 79 65 72 3e 0a 3c  |er>.  </Layer>.<|
    000018e0  2f 43 61 70 61 62 69 6c  69 74 79 3e 0a 3c 2f 57  |/Capability>.</W|
    000018f0  4d 54 5f 4d 53 5f 43 61  70 61 62 69 6c 69 74 69  |MT_MS_Capabiliti|
    00001900  65 73 3e 0a 00 14 00 00  00 14 00 00 00 14 00 00  |es>.............|
    00001910  00 14 00 00 00 14 00 00  00 14 00 00 00 14 00 00  |................|
    00001920  00 14 00 00 00 14 00 00  00 14 00 00 00 14 00     |...............|

Is it a known bug? I'm afraid this kind of garbage can produce
undesirable effects in WMS support. For this simples example I can
"manually" remove it but I'm not sure how to deal with it in other
cases. I'll be greatful if you could give me some light.


Best regards, 

There was a problem in th stripcontentheader function, and I have committed
a change I hope will fix it. 

Assefa, 

Is the ctx->readWriteFunc != msIO_bufferWrite problem still there?  
I restructured things so this should be gone (a number of weeks ago). 

I'm going to close this report since I think the RFC is complete, and that
problem is fixed.  Please reopen if that is not the case.