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

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht at gmail.com> writes:

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

Yup, will try to set one up soonish. ENOTIME so far.

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

Oh, sure, quite happy with more implementations. That was option 3.
However, until someone actually starts working on such an implementation
this is all hypothetical. I'm happy to discuss interoperability issues
when such an implementation actually materialises :)

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

Yes, but .json.gz also makes it hard to distinguish from other random
gzip'ed json data. I'd rather have a separate file extension for offline
storage, and then solve the web problem as a separate problem, which as
far as I'm concerned is orthogonal to the encoding of the files on disk.
The important thing is the structure of the JSON object, not which
compression format and file extension it is stored in.

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

And odds are that db back end is going to store the JSON object in its
own encoding anyway, hence rendering this whole discussion moot... :)

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

Yeah, I'm sceptical, but willing to give it the benefit of the doubt if
it means I have to write less code...

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

Yes, well, matplotlib is not exactly a cheetah...

-Toke