[TinyOWS-dev] About encoding per layer and other things

[Carlos Ruiz]

Olivier,

No problem about the delay, I'm quite busy too.

You're right, I forgot to use the ->buf to get the buffer contents as char *, 
which I already did on my 

linux server when make complained. I'm really sorry to send you the .patch file 
with thatmistake.

It's fine to remove the author comments I made, I just added them as a good 
practice.

Well, I'll add a new dbEncoding attribute in the general section toset the 
client encoding once the 

connection is opened to right handling the varchar values in the INSERT/UPDATE 
statements within the 

transaction.

The possible values of this attribute will not be validated by TinyOWS and also 
it must be include the link 

to the PostgreSQL supported encodings

http://www.postgresql.org/docs/9.0/static/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED


into the TinyOWS documentation.

>WFS-T specification already have a way to handle explicitly locks
>But i didn't implemented them in TinyOWS for now.

>If you have to explore this way, you should also have a look in PostGIS Long 
>Transaction features.
>A patch for WFS-T lock implementation is welcome (since it's strictly conform to 
>OGC WFS-T spec)

>But there's some problem IMHO in this OGC lock architecture,as the client have 
>to release himself 
>
>each lock he already tooks.(And sometime client will just forget too, or could 
>exploit this feature as a 
>
>security hole, kind of quick DoS)

>So GeoServer for instance also provide via administration backoffice,a way for 
>administrator to list 
>
>each lock and a way to release them if  needed.

>And on the final point, i'm not sure that there's available WFS-T client 
>appsable to deal with WFS 
>
>lock handle...

It isn't a good idea to allow the client to handle LOCKs. PostgreSQL 
automatically detects deadlocks:

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.) 


I will take a look to the PostGIS long transaction features and the OGC WFS-T 
specification.

There's another failure with the CRS on gvSIG, it just throws an exception while 
parsing it, I'll check for that 

too.

Cheers

IC Carlos Ruiz


From: Olivier Courtin <olivier.courtin at gmail.com>

To: TinyOWS developers discuss list <tinyows-dev at lists.maptools.org>
Sent: Fri, February 4, 2011 5:04:29 AM
Subject: Re: [TinyOWS-dev] About encoding per layer and other things


On Feb 1, 2011, at 11:27 PM, Carlos Ruiz wrote:

Hi Carlos,

First sorry for the delay...

> I was checking about the per layer encoding.
>
> First, when I've added the encoding attribute in the config.xml  
> file, it was to be able to pull data from
> the server with the GetFeature request.
>
> This because I noticed that Quantum GIS wasn't loading my data  
> complete. Doing some tests with
> the GetFeature request with a browser, there was a parsing error  
> with no UTF-8 characters.
>
> That problem was now fixed with the changes I made, you can check at
>
> http://sitel.jalisco.gob.mx/cgi-bin/wfst2?SERVICE=WFS&VERSION=1.0.0&REQUEST=
>       GetFeature&TYPENAME=sitel:acatic_manzanas
>
> to see that the TinyOWS generated XML response handles the encoding  
> ISO-8859-1 that I've
> defined into my config.xml file.
>
> Also, if you type ./wfst2 --check it dumps the encoding too:
>
> TinyOWS version:   0.9.0
> Config File Path:  /usr/local/tinyows/config.xml
> PostGIS dsn:       host=127.0.0.1 ...
> Schema dir:        /usr/local/tinyows/schema/
> Log file:          /usr/local/tinyows/tinyows.log
> Encoding:          ISO-8859-1
> Available layers:
> - public.acatic_manzanas  -> 32613 RW
> - public.acatic_cultivos  -> 32613 RW
> - public.acatic_curvas_nivel_maestras  -> 32613 RW
>
> Now, handling encoding per layer needs to specify per table  
> PostgreSQL encodings, is not possible
> because you can only set the encoding to the whole database.

Yeap that's a good point, you're right !

> Also, there's no necessarily match between the XML encoding and the  
> PostgreSQL encoding.
>
> Lets say:
>
> I need to handle the XML responses with an encoding that supports  
> french and spanish special
> characters, so I have to choose ISO-8859-1, but, I have my database  
> configured as LATIN-1
> or WIN1252. It doesn't match.
>
> So I suggest to add into the pg tag an encoding attribute, like this:
> <pg host="127.0.0.1" user="postgres" password="postgres"
> dbname="tinyows_demo" port="5432"
> encoding="LATIN-1"/>

It could be,
But the global location in OWS also seems fine to me.

> With this change, I just can call the PQsetClientEncoding function  
> after the connection is
> open.
>
> What do you think ?

+1

I've took your last patch,
and made few modification before commit in trunk.

Thanks a lot ! :)

I let you check that everything is fine on your own,

Few little things from previous patch:
- Buffer struct is not directly a char * , but you could use buffer- 
>buf if needed
- I didn't keep author comment inside the code (svn log and NEWS files  
are dedicaded for that)


> There's another thing I'm seeing with the transaction code. It will  
> be wise to use SELECT ... WITH
> UPDATE specification and also adding LOCKs while update or delete  
> rows, to avoid concurrency
> problems.
>
> However, this change might affect a little bit the performance  
> (because the locks) but
> enhancing the
> data consistency.
>
> I'm currently doing some tests with that.

WFS-T specification already have a way to handle explicitly locks
But i didn't implemented them in TinyOWS for now.

If you have to explore this way, you should also have a look in  
PostGIS Long Transaction features.
A patch for WFS-T lock implementation is welcome (since it's strictly  
conform to OGC WFS-T spec)

But there's some problem IMHO in this OGC lock architecture,
as the client have to release himself each lock he already tooks.
(And sometime client will just forget too, or could exploit this  
feature as
a security hole, kind of quick DoS)

So GeoServer for instance also provide via administration backoffice,
a way for administrator to list each lock and a way to release them if  
needed.

And on the final point, i'm not sure that there's available WFS-T  
client apps
able to deal with WFS lock handle...


--
Olivier
_______________________________________________
TinyOWS-dev mailing list
TinyOWS-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tinyows-dev



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-dev/attachments/20110204/71e70641/attachment.htm