[sr-dev] rtpproxy-ng

Daniel-Constantin Mierla miconda at gmail.com
Wed Jul 10 20:28:56 CEST 2013

On 7/10/13 6:07 PM, Richard Fuchs wrote:
> On 07/10/13 11:32, Daniel-Constantin Mierla wrote:
>> Are there pretty-printing tools for bencode? Or just 'gateways' to
>> json/xml pretty-printing.
> There's an online one here: http://pauw.student.utwente.nl/bencode.html
> Or you can easily make one yourself. For example in Perl, using one of 
> the existing bencode modules, it's about a 2-liner script. Same in 
> PHP, or Python, or ...
It was not about 'do it yourself', but commodity for average users to 
deal with it ...

>> I was referring to post-processing -- i.e., do the queries periodically
>> or for each call at the end, store the results in a storage system and
>> then generate reports. With json, in some systems you can simply refer
>> to it as a structure, like:
>> result.totals.input.rtp.bytes>1000
>> This kind of operations makes very easy generating reports.
> I'm not sure I understand the problem. In order to access elements of 
> a JSON object, the whole JSON string has to be parsed and processed.

It's again about existing tools/storage systems -- they have built-in to 
access json as an object/variable, no need to parse yourself and build a 
custom/own query language. Just for example, iirc, at some point I saw a 
patch/presentation that MariaDB can do optimized searching withing json 
object by matching with dedicated functions (as well as capability of 
setting just a value inside json docs).

> The same is true for bencode. After decoding, elements can be accessed 
> in whatever way the language and library used supports. There's no 
> reason why bencode data can't be accessed the same way JSON data can 
> be accessed. The structure of the data is the same.

That will required development in all these systems, both can be seen as 
serialization mechanisms, but their structure is different, so existing 
json functions in one system cannot be reused.
> Unless you're talking about an immutable system which only supports 
> but can't support JSON. In that case you can either directly translate 
> bencode to JSON, or teach either the RTP proxy or the module to also 
> produce JSON output when needed. But I'm not familiar with any such 
> systems, so can't really provide any useful input.
You implemented and it was your decision, so I don't have anything 
against using bencode in this case -- in the light of requests for 
comments you asked for, I tried to figure out if parsing faster bencoded 
strings pays off when balancing with the need to interact with/from 
different components in a complete operational platform.


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

More information about the sr-dev mailing list