Re: [Bloat] Announcing Flent (formerly netperf-wrapper) v0.10.0

[Dave Taht <dave.taht@gmail.com>]

well,1) we need a flent-devel mailing list... no need to have this
discussion so widely here..

On Sun, May 24, 2015 at 10:55 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> This contained the never-merged (some licencing issues) web based
>> parser for the data.
>>
>> https://github.com/bipulkkuri/netperf-wrapper
>
> The main reason (apart from licensing issues) that it was never merged
> was that I don't want to maintain two plotting implementations within
> Flent itself. So the possible scenarios for a web-based viewer are, as I
> see it, roughly:

I agree that *you* do not want to maintain two plotting
implementations inside flent. But:

I am hugely in favor of various implementations of stuff that can read
the file format and do various (new and interesting) things with it.
The number of python-matplotlib capable developers is small. The
number of javascript capable developers (and web based plotting tools)
is huge. Other means of dealing with the data (postgres json) are also
needed.

So the json.gz file format WAS readable and translatable by many web
servers and browsers, flent is not (so far as I know, even with adding
a mime type.)

I liked the original web based prototype, it needed a db back end, but
it seemed like a promising start.

> 1. Leverage the existing matplotlib plotting implementation to produce
>    javascript plots. This is issue #27
>    (https://github.com/tohojo/flent/issues/27) and depends on how well
>    the mpl-to-d3 library works in practice.

I don't have a lot of hope for the canvas approach, personally. Too
many abstractions.

>
> 2. Replace the whole plotting implementation with a javascript-based
>    one, and serve that from within Flent itself.

No, trying to optimize for local full throttle use make the tool most
useful for core developers.

>
> 3. Have an entirely separate web viewer implementation.
>
>
> Which scenario that works best will probably to a large extent depend on
> the actual use case this mystical beast is supposed to support. Which I
> don't believe has been articulated properly...

All three could be done.  (with sufficient developers with sufficient
skillsets with sufficient funding)

Personally what I most prefer is that the "expert" implementation be
blazing fast!

The third option makes it more possible to share and compare the
results over many browser types and OSes, including (ugh) windows.

> -Toke



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67