JsvReader don't work with CultureInfo.CreateSpecificCulture("pt-BR")

[GoogleCodeExporter]

When my culture is pt-BR one of my objects is inserted into redis as:

  {Latitude:-23,5707,Longitude:-46,57239}

As you can see, in this culture the decimal separator is the same as the 
field separator and JsvReader can't read it and throws a 
IndexOutOfRangeException.

A workaround is to set the current culture to CultureInfo.InvariantCulture, 
but I would like it to work in any culture.

I know this is mainly a .NET bug, that JsvSerializer and JsvReader should 
be internationalized, but as .NET bugs won't be solved as fast as we need, 
I think this library should provide a workaround for this bug.

Original issue reported on code.google.com by jad...@gmail.com on 28 May 2010 at 3:07

[GoogleCodeExporter]

I thought JsvReader was a .NET class, now I realize it is a ServiceStack's 
class, and 
.NET has no bugs.

Original comment by jad...@gmail.com on 28 May 2010 at 3:11

[GoogleCodeExporter]

Can someone edit my post to correct this?

Original comment by jad...@gmail.com on 28 May 2010 at 3:12

[GoogleCodeExporter]

Hi jaderd,

I've just seen the issue now. Looks like I didn't think to escape floating 
point numbers since I always assumed 
'.' like a proper westerner :)

Anyway I'll try get onto a fix this weekend. I'll let you know on this thread 
when its done.

Unfortunately the admin UI here only lets me delete the last 2 comments you've 
sent and cannot edit the 
original issue. I don't think there's anything to worry about as it a natural 
misunderstanding that anyone 
could make.

Original comment by demis.be...@gmail.com on 28 May 2010 at 3:55

[GoogleCodeExporter]

Thanks for your time demis.
I see that JsvSerializer is very close to JavascriptSerializer, but I belive 
your team 
had reasons to implement such class. The default behavior of 
JavascriptSerializer is to 
serialize everything using CultureInfo.InvariantCulture, and parse it using the 
same 
culture. I don't think you should escape numbers.
I also would like to point that pt-BR is also a western culture, besides using 
a 
different decimal separator.

Original comment by jad...@gmail.com on 28 May 2010 at 4:38

[GoogleCodeExporter]

The main reason for inventing Jsv format is because existing Json serializers 
in .NET were too slow. 
More detail about the reasoning and benefits behind the new format are 
available at: http://www.servicestack.net/mythz_blog/?p=176

JavascriptSerializer is the slowest of all. I've got benchmarks showing it over 
240x slower than protobuf (basically don't ever use it), if 
you want a JSON serializer I recommend that you use JsonDataContractSerializer 
or James Newton JSON.NET's serializer.

Ok thanks for the tip of using InvarantCulture - definitely the way to go so 
your serialized data can be deserializable from anywhere. Will 
implement the fix with this approach.

Original comment by demis.be...@gmail.com on 28 May 2010 at 5:13

[GoogleCodeExporter]

I liked your Jsv format. I wonder if your implementation could be modified to 
generate 
JSON/Javascript as fast as it does Jsv.

Original comment by jad...@gmail.com on 30 May 2010 at 8:34

[GoogleCodeExporter]

Wouldn't JSV be more compact if it used double commas (,, replacing single 
commas) 
instead of double quotes (" at the end and the beggining of a string) to escape 
strings 
?

(I know it's too late to change that)

Original comment by jad...@gmail.com on 30 May 2010 at 8:38

[GoogleCodeExporter]

Hey jaderd, 

Yeah I think it's possible to port the 'JSV' approach to a JSON format and get 
a lot better perf than what is currently available. It 
won't be as fast (the format does help) but I'd imagine should still be within 
a comparable range. @marcgravell from 
http://code.google.com/p/protobuf-net/ has hinted that after his v2 rewrite 
that he might be interested in re-using his tech and 
consider implementing a JSON format. If he does that should end up being the 
fastest possible implementation since its mostly custom 
Reflection emitted and avoids all type casts.

I'm in no hurry since there are a few options available and will wait to see 
what @marcgravell decides what he's going to do. Either 
that or hopefully Microsoft's lifts their game and ships a better serializer :)

As for the ",," that would be a good approach if the only thing I had to escape 
was commas. Unfortunately to remain lexically parse-
able I have to escape all special chars i.e. []{},". Also having it use 
CSV-style escaping means that it would be trivially possible 
to re-project an array of JSV objects into a CSV dataset without any 
de-serialization.

Original comment by demis.be...@gmail.com on 30 May 2010 at 9:06

[GoogleCodeExporter]

thank you for your explanation

Original comment by jad...@gmail.com on 30 May 2010 at 9:51

[GoogleCodeExporter]

Hi jaderd,

Sorry for the delay, spent some time away from the computer to enjoy the long 
weekend :)

I've released a new version of all ServiceStack binary releases to 1.31 which 
should include the latest fixes.
Let me know if it works for you so I can close this ticket.

Cheers,
Demis

Original comment by demis.be...@gmail.com on 2 Jun 2010 at 1:32

[GoogleCodeExporter]

Hi Demis,
I tried to test, but then I realized that since I migrated from Redis to 
Memcached I'm 
not using Jsv anymore. I was investigating why and I found that your 
MemcachedClient is 
just an interface to Enyim's.
Do you plan to implement a MemcachedClient that uses Jsv instead of the default 
serializers?

Original comment by jad...@gmail.com on 2 Jun 2010 at 6:44

[GoogleCodeExporter]

Hi jaderd,

Ok fine no problem. Since memcached is more a 'cache' then a 'persistence 
store' it probably makes sense to use either 
the most 'optimal serialization format' (protocol buffers) or the final 'output 
serialization format'. E.g. with a 
cache you do not expect to inspect, manipulate or version the content so you 
should optimize for your use case.

For the most optimal format I would consider looking at protocol buffers, again 
@marcgravell he has an adapter that 
lets you use memcached configured with his protobuf-net library here:
http://marcgravell.blogspot.com/2010/01/distributed-caching-with-protobuf-net.ht
ml

Although in most cases what would be faster is to use the 'output serialization 
format', if its a web page that would 
mean the html, and for a web service either JSON or XML. This would be faster 
because no deserialization would be 
required at all and you can write the payload directly to the response stream. 
Also depending on the size of the 
payload you may also want to consider using the web standard deflate/gzip 
compression.

Original comment by demis.be...@gmail.com on 2 Jun 2010 at 7:01

[GoogleCodeExporter]

Hi Demis,

 Thank you for your exhaustive (in a good sense) explanation again. I understand now 
your reasoning, and as you might have guessed I'm not using memcached for 
caching :).

 I'll look into marcgravell library.

Original comment by jad...@gmail.com on 2 Jun 2010 at 11:54

[GoogleCodeExporter]

Original comment by demis.be...@gmail.com on 2 Jun 2010 at 11:58

• Changed state: Fixed