On Sun, May 24, 2015 at 11:16 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Dave Taht <dave.t...@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 :)
Well, no. Usually we discuss interop issues in file and wire formats in light of *possible* implementations... and a web implementation of some plotting tools is a highly desirable implementation. >> 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. All in favor of .flent.gz. and .flent.bz. Not .flent the compressed json encoded format. > 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... :) And odds are that the db backend would only store the metadata and not the raw data. >> 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... Goal here is to make it as easy as possible for *others* to write code. >> Personally what I most prefer is that the "expert" implementation be >> blazing fast! > > Yes, well, matplotlib is not exactly a cheetah... Yes, on my bad days, waiting for 100+ plots to render on my 16 core box, I dream of rewriting the whole thing in go and parallizing the hell out of it, for starters. > > -Toke -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat