[sr-dev] [PATCH 1/1] websocket: remove libunistring dependency

[Daniel-Constantin Mierla]

Was there any resolution on this topic? I would like to get rid of the 
unnecessary dependency, the code looked fine at a quick check -- if it 
is just about utf8 encoding/decoding.

Eventually it can be made a compile time switch with defines for both 
options, keep the code for both cases and be able to easily switch from 
one to another.

Cheers,
Daniel

On 20/12/13 15:45, Peter Dunkley wrote:
> On 20 December 2013 14:09, Timo Teras <timo.teras at iki.fi 
> <mailto:timo.teras at iki.fi>> wrote:
>
>     On Fri, 20 Dec 2013 13:56:08 +0000
>     Peter Dunkley <peter.dunkley at crocodile-rcs.com
>     <mailto:peter.dunkley at crocodile-rcs.com>> wrote:
>
>     > One of the reasons I used libunistring for this detection is
>     that for
>     > pretty much all of the code fragments I found online for doing this
>     > in a "simple" way I saw people pointing out flaws in those
>     > algorithms.  Can you confirm that this code doesn't have any of
>     those
>     > flaws and is guaranteed to work in all cases (has this
>     implementation
>     > been stubbed out and tested fully by someone here)?
>
>     Did you read the document on the URL it refers to? It is quite
>     thorough
>     explanation of what it does, it's correctness and speed. It also
>     explains that the motivation for implementing it was because all those
>     snippets in the internet are seriously flawed.
>
> I did see the document.  It looks good.  Does you have first hand 
> experience of whether that code is valid and correct or not?
>
> I personally tend to trust a release library from GNU somewhat more 
> than code on a web-site - however good that web-site and documentation 
> looks.
>
>
>     > Does this really improve performance?  Only a tiny, tiny, subset of
>     > libunistring is used.  As a result it doesn't really matter if
>     > libunistring in general is slow, just whether or not the one
>     function
>     > used from libunistring is slow.
>
>     I'm referring specifically to the function you use. Please check the
>     URL for performance comparison. While libunistring is not benchmarked
>     separately, one can see with 0.1 second look at libunistring's
>     implementation that it will be slower in performance and is likely
>     something close to iconv()'s implementation.
>
>
> I don't have any objection to this change as long as you are 100% sure 
> that the algorithm from that web-page works correctly.  The algorithm 
> looks good, the web-page looks good, the documentation looks good, but 
> I'd really prefer it if the implementation was explicitly and fully 
> tested before the libunistring call is replaced.
>
> Something as simple as a loop through all possible values calling your 
> function, the libunistring function, and comparing the results would 
> be perfect.
>
> Regards,
>
> Peter
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140204/4f818b68/attachment.html>