From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 353BE20001D for ; Sun, 24 May 2015 11:34:29 -0700 (PDT) Received: by obbnx5 with SMTP id nx5so42265876obb.0 for ; Sun, 24 May 2015 11:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X7kauNN832wwfeXc/icD7rIBzlRLNDMFkeHyKRb9AEU=; b=MwT2olaJq3SalGD9H1ZukalvX0OYeAd8LygiV011qXPKLFNeslOaSGnFwPbSfYPXxr bp2ydTmPC2Jar+aS4j7JpDa/OJi0893VRmZc2KKun0wgdckP8UiGQJnrBafTvptNbfWg ecKqmDamWEWlbZj9LTDp31/a+VT7H/ksPbCEnSVZU7INO6y0Wzeueg89ztOzCuQgv83U /htCALRUwpz2kLKA+ipHRyrnQWvyf5TcEGH2HnFcHeJ5lH7hZFgAUMxIItPsJfInOZsG ysf7vRujyLK/ZjLyj1DSy6D5bS++7AqajstPe2VnPg5rqZfBN2ogQguqs4TDUZ4/fKyG bCKw== MIME-Version: 1.0 X-Received: by 10.202.71.84 with SMTP id u81mr6499979oia.81.1432492466156; Sun, 24 May 2015 11:34:26 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Sun, 24 May 2015 11:34:26 -0700 (PDT) In-Reply-To: <87y4kdet8p.fsf@toke.dk> References: <877frygk7e.fsf@toke.dk> <87a8wtg8si.fsf@toke.dk> <87y4kdet8p.fsf@toke.dk> Date: Sun, 24 May 2015 11:34:26 -0700 Message-ID: From: Dave Taht To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Announcing Flent (formerly netperf-wrapper) v0.10.0 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 18:35:17 -0000 On Sun, May 24, 2015 at 11:16 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Dave Taht 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 --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67