Some feedback

[Waldir Pimenta]

On Mon, Jun 17, 2013 at 3:47 PM, Joachim Breitner
<mail at joachim-breitner.de>wrote:

> Hi,
>
> Am Montag, den 17.06.2013, 04:36 +0100 schrieb Waldir Pimenta:
>
> > Sorry, I didn't phrase it well. I meant if you know of any software
> > project page (yours or not) that you particularly like and from which
> > we could borrow some ideas :)
>
> http://info-beamer.org/ looks nice, but feel free do to what you like.
>

Got it. I'll get back to the list later with a proposal which we can
iterate on.


> >         I like to know that the background program uses minimal
> resources;
> >         appending a few bytes to a file is good there. If the
> possibilities you
> >         talk about are about other people writing code to use the data,
> then a
> >         nicer dumping format can serve the same purpose.
> >
> >         As more more analysis in arbtt-stats (or arbtt-graph or
> whatever): There
> >         are endless possibilities, and so little time :-). I’d prefer to
> >         implement stuff with a concrete usecase, preferably also with a
> little
> >         outline (e.g. a sketch of an graph or of intended output) and
> some
> >         discussion if it is not possibly covered by exiting features, or
> can
> >         maybe simplified or generalized.
> >
> >
> > Responding to both paragraphs above: Yes, I meant the (imho)
> > improvements to both the binary storage and the text-based dumping
> > format as ways to enable others to build cool stuff on top of arbtt.
> > Lots of people are comfortable with other programming languages and
> > this would expand the arbtt ecosystem beyond Haskell-proficient
> > programmers :) I think arbtt can certainly be enhanced, but I don't
> > feel it really needs many more features on its own. I like the way it
> > does a few things very well (capturing the data and storing it
> > efficiently is what I personally appreciate the most), and making it
> > more interoperable with other tools would, I believe, greatly expand
> > its potential (besides bringing it even closer to the Unix philosophy
> > ideal ;) )
>
> agreed, but that need would be served by a JSON-dump-format in
> arbtt-dump, wouldn’t it?


I'd say so, yes. For quick hacks, especially, I suppose a JSON export and
the filtering commands mentioned earlier will be enough. Of course, it is
impossible to predict what people would think of, so the filters provided
might not suit a particular hacker's needs. Processing the text dump is
doable, but ideally, I assume some performance would be lost in the
exporting to text through arbtt-dump and parsing by the target program,
when direct db access could arguably be faster. Of course, this is just an
hypothetical disadvantage of a hypotethical application, so if converting
to sqlite would entail non-trivial changes, I guess it can be said to
amount to premature optimization and therefore undesirable for now :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nomeata.de/pipermail/arbtt/attachments/20130617/0ce7b67c/attachment.htm>