RFC 16: MapScript WxS Services

[mapserver-bot]

Reporter: warmerdam
Date: 2006/05/22 - 20:36
Trac URL: http://trac.osgeo.org/mapserver/ticket/1788

This bugs is to track implementation of RFC 16.

  http://mapserver.gis.umn.edu/development/rfc/ms-rfc-16-mapscript-wxs-services/

[mapserver-bot]

Author: hobu
Date: 2006/05/22 - 22:38

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

[mapserver-bot]

Author: fwarmerdam
Date: 2006/05/23 - 19:55

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.  

[mapserver-bot]

Author: dmorissette
Date: 2006/05/24 - 20:05

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

[mapserver-bot]

Author: fwarmerdam
Date: 2006/05/24 - 20:39

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.  

[mapserver-bot]

Author: assefa
Date: 2006/05/29 - 18:21

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

[mapserver-bot]

Author: assefa
Date: 2006/05/29 - 21:23

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.

[mapserver-bot]

Author: fwarmerdam
Date: 2006/06/02 - 16:38

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

[mapserver-bot]

Author: vilson.farias@digitro.com.br
Date: 2006/08/09 - 16:17

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, 

[mapserver-bot]

Author: fwarmerdam
Date: 2006/08/09 - 16:40

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

[mapserver-bot]

Author: fwarmerdam
Date: 2006/08/16 - 21:41

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. 

[ejn]

Sorry to get archaelogical on this one, but from the RFC the function

msIO_setStdinBuffer( unsigned char *data, int length );

has never been implemented. While digging about in msio.c I spotted the following too:

int msIO_bufferRead( void *cbData, void *data, int byteCount )
{
  /*    msIOBuffer *buf = (msIOBuffer *) cbData; */
  /* not implemented yet. */
  return 0;
}

On the other hand the function msIO_installStdinFromBuffer() does appear to be implemented, and even available in Mapscript, despite in the light of the above being of "limited use".

On the one hand, something which has obviously not been needed in the last 8 years could be said to be not needed at all. On the other hand, the RFC and the function msIO_installStdinFromBuffer()promise this functionality and I can see good uses for it with Mapscript applications.

I propose that either:

1. a note is added to the RFC that this functionality was never implemented and msIO_installStdinFromBuffer() (and msIO_bufferRead ?) be removed, or at least prominently marked as deprecated
2. this functionality be implemented ;-) - together with appropriate Mapscript bindings

@warmerdam Is there a non-obvious reason that this part of the RFC never got implemented?

Of course I think (2) is the better solution, but unfortunately I'm not going to be volunteering to do it anytime soon! (1) I could probably manage...

btw: feel free to close this as a "won't fix" or to separate the relevant bits into a separate ticket!

[mapserver-bot]

This is an automated comment

This issue has been closed due to lack of activity. This doesn't mean the issue is invalid, it simply got no attention within the last year. Please reopen with missing/relevant information if still valid.

Typically, issues fall in this state for one of the following reasons:

• Hard, impossible or not enough information to reproduce
• Missing test case
• Lack of a champion with interest and/or funding to address the issue