<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10pt"><span style="font-family: arial,helvetica,sans-serif;">Olivier,</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">No problem about the delay, I'm quite busy too.</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">You're right, I forgot to use the <span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">->buf</span> to get the buffer contents as <span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">char *</span>, </span><span style="font-family: arial,helvetica,sans-serif;">which I already did on my <br>linux server
when <span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">make</span> complained. I'm really sorry to send you the <span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">.patch</span> file with that</span><span style="font-family: arial,helvetica,sans-serif;"> mistake.</span><br><br><span style="font-family: arial,helvetica,sans-serif;">It's fine to remove the author comments I made, I just added them as a good practice.</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">Well, I'll add a new <font style="font-family: Courier New,courier,monaco,monospace,sans-serif;" size="2">dbEncoding</font> attribute in the general section to</span><span style="font-family: arial,helvetica,sans-serif;"> set the client encoding once the <br>connection is opened to right handling the varchar values in the
INSERT/UPDATE statements within the <br>transaction.<br><br>The possible values of this attribute will not be validated by TinyOWS and also it must be include the link <br>to the PostgreSQL supported encodings</span><span style="font-family: arial,helvetica,sans-serif;"><br><br><a href="http://www.postgresql.org/docs/9.0/static/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED">http://www.postgresql.org/docs/9.0/static/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED<br></a><br>into the TinyOWS documentation</span><span style="font-family: arial,helvetica,sans-serif;">.</span><br><span style="font-family: arial,helvetica,sans-serif;"><br>>WFS-T specification already have a way to handle explicitly locks</span><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">>But i didn't implemented them in TinyOWS for now.</span><br style="font-family: arial,helvetica,sans-serif;">
<br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">>If you have to explore this way, you should also have a look in </span><span style="font-family: arial,helvetica,sans-serif;">PostGIS Long Transaction features.</span><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">>A patch for WFS-T lock implementation is welcome (since it's strictly </span><span style="font-family: arial,helvetica,sans-serif;">conform to OGC WFS-T spec)</span><br>
<br><span style="font-family: arial,helvetica,sans-serif;">>But there's some problem IMHO in this OGC lock architecture,</span><span style="font-family: arial,helvetica,sans-serif;"> as the client have to release himself <br>>each lock he already tooks.</span><span style="font-family: arial,helvetica,sans-serif;"> (And sometime client will just forget too, or could exploit this </span><span style="font-family: arial,helvetica,sans-serif;">feature as a <br>>security hole, kind of quick DoS)</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">>So GeoServer for instance also provide via administration backoffice,</span><span style="font-family: arial,helvetica,sans-serif;">a way for administrator to list <br>>each lock and a way to release them if </span><span style="font-family:
arial,helvetica,sans-serif;">needed.</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">>And on the final point, i'm not sure that there's available WFS-T </span><span style="font-family: arial,helvetica,sans-serif;">client apps</span><span style="font-family: arial,helvetica,sans-serif;"> able to deal with WFS <br>>lock handle...</span><br><span style="font-family: arial,helvetica,sans-serif;"></span><br><span style="font-family: arial,helvetica,sans-serif;">It isn't a good idea to allow the client to handle LOCKs. PostgreSQL automatically detects deadlocks:<br><br></span><span style="font-style: italic; font-family: arial,helvetica,sans-serif;" class="PRODUCTNAME"></span><span style="font-style: italic; font-family: arial,helvetica,sans-serif;"> PostgreSQL automatically detects deadlock
situations and resolves them by aborting one of the transactions
involved, allowing the other(s) to complete. (Exactly which
transaction will be aborted is difficult to predict and should not
be relied upon.) </span><br style="font-style: italic; font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;"><br>I will take a look </span><span style="font-family: arial,helvetica,sans-serif;">to the </span><span style="font-family: arial,helvetica,sans-serif;">PostGIS long transaction features and the </span><span style="font-family: arial,helvetica,sans-serif;">OGC WFS-T specification.</span><br><br><font size="2"><span style="font-family: arial,helvetica,sans-serif;">There's another failure with the CRS on gvSIG, it just throws an exception while parsing it, I'll </span><span style="font-family: arial,helvetica,sans-serif;">check for that <br>too.</span><br><br style="font-family: arial,helvetica,sans-serif;"></font><span style="font-family: arial,helvetica,sans-serif;">Cheers</span><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;"><br><span
style="font-weight: bold; color: rgb(0, 96, 191);">IC Carlos Ruiz</span></span><br style="font-weight: bold; color: rgb(0, 96, 191);"><div style="font-weight: bold; color: rgb(0, 96, 191);"><br></div><div style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 10pt;"><b><span style="font-weight: bold;">From:</span></b> Olivier Courtin <olivier.courtin@gmail.com><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><b><span style="font-weight: bold;">To:</span></b> TinyOWS developers discuss list <tinyows-dev@lists.maptools.org><br><b><span style="font-weight: bold;">Sent:</span></b> Fri, February 4, 2011 5:04:29 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [TinyOWS-dev] About encoding per layer and other things<br></font><br>
<br>On Feb 1, 2011, at 11:27 PM, Carlos Ruiz wrote:<br><br>Hi Carlos,<br><br>First sorry for the delay...<br><br>> I was checking about the per layer encoding.<br>><br>> First, when I've added the encoding attribute in the config.xml <br>> file, it was to be able to pull data from<br>> the server with the GetFeature request.<br>><br>> This because I noticed that Quantum GIS wasn't loading my data <br>> complete. Doing some tests with<br>> the GetFeature request with a browser, there was a parsing error <br>> with no UTF-8 characters.<br>><br>> That problem was now fixed with the changes I made, you can check at<br>><br><span>> <a target="_blank" href="http://sitel.jalisco.gob.mx/cgi-bin/wfst2?SERVICE=WFS&VERSION=1.0.0&REQUEST">http://sitel.jalisco.gob.mx/cgi-bin/wfst2?SERVICE=WFS&VERSION=1.0.0&REQUEST</a>=</span><br>>
GetFeature&TYPENAME=sitel:acatic_manzanas<br>><br>> to see that the TinyOWS generated XML response handles the encoding <br>> ISO-8859-1 that I've<br>> defined into my config.xml file.<br>><br>> Also, if you type ./wfst2 --check it dumps the encoding too:<br>><br>> TinyOWS version: 0.9.0<br>> Config File Path: /usr/local/tinyows/config.xml<br>> PostGIS dsn: host=127.0.0.1 ...<br>> Schema dir: /usr/local/tinyows/schema/<br>> Log file: /usr/local/tinyows/tinyows.log<br>> Encoding: ISO-8859-1<br>> Available layers:<br>> - public.acatic_manzanas -> 32613 RW<br>> - public.acatic_cultivos -> 32613 RW<br>> - public.acatic_curvas_nivel_maestras -> 32613 RW<br>><br>> Now, handling encoding per layer needs to specify per table <br>>
PostgreSQL encodings, is not possible<br>> because you can only set the encoding to the whole database.<br><br>Yeap that's a good point, you're right !<br><br>> Also, there's no necessarily match between the XML encoding and the <br>> PostgreSQL encoding.<br>><br>> Lets say:<br>><br>> I need to handle the XML responses with an encoding that supports <br>> french and spanish special<br>> characters, so I have to choose ISO-8859-1, but, I have my database <br>> configured as LATIN-1<br>> or WIN1252. It doesn't match.<br>><br>> So I suggest to add into the pg tag an encoding attribute, like this:<br>> <pg host="127.0.0.1" user="postgres" password="postgres"<br>> dbname="tinyows_demo" port="5432"<br>> encoding="LATIN-1"/><br><br>It could be,<br>But the global location in OWS also seems fine to me.<br><br>> With this change, I just can call the PQsetClientEncoding function
<br>> after the connection is<br>> open.<br>><br>> What do you think ?<br><br>+1<br><br>I've took your last patch,<br>and made few modification before commit in trunk.<br><br>Thanks a lot ! :)<br><br>I let you check that everything is fine on your own,<br><br>Few little things from previous patch:<br>- Buffer struct is not directly a char * , but you could use buffer- <br> >buf if needed<br>- I didn't keep author comment inside the code (svn log and NEWS files <br>are dedicaded for that)<br><br><br>> There's another thing I'm seeing with the transaction code. It will <br>> be wise to use SELECT ... WITH<br>> UPDATE specification and also adding LOCKs while update or delete <br>> rows, to avoid concurrency<br>> problems.<br>><br>> However, this change might affect a little bit the performance <br>> (because the locks) but<br>> enhancing the<br>> data consistency.<br>><br>> I'm
currently doing some tests with that.<br><br>WFS-T specification already have a way to handle explicitly locks<br>But i didn't implemented them in TinyOWS for now.<br><br>If you have to explore this way, you should also have a look in <br>PostGIS Long Transaction features.<br>A patch for WFS-T lock implementation is welcome (since it's strictly <br>conform to OGC WFS-T spec)<br><br>But there's some problem IMHO in this OGC lock architecture,<br>as the client have to release himself each lock he already tooks.<br>(And sometime client will just forget too, or could exploit this <br>feature as<br>a security hole, kind of quick DoS)<br><br>So GeoServer for instance also provide via administration backoffice,<br>a way for administrator to list each lock and a way to release them if <br>needed.<br><br>And on the final point, i'm not sure that there's available WFS-T <br>client apps<br>able to deal with WFS lock
handle...<br><br><br>--<br>Olivier<br>_______________________________________________<br>TinyOWS-dev mailing list<br><a ymailto="mailto:TinyOWS-dev@lists.maptools.org" href="mailto:TinyOWS-dev@lists.maptools.org">TinyOWS-dev@lists.maptools.org</a><br><span><a target="_blank" href="http://lists.maptools.org/mailman/listinfo/tinyows-dev">http://lists.maptools.org/mailman/listinfo/tinyows-dev</a></span><br></div></div>
</div><br>
</body></html>