<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 17, 2013 at 3:47 PM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Am Montag, den 17.06.2013, 04:36 +0100 schrieb Waldir Pimenta:<br>
<div class="im"><br>
> Sorry, I didn't phrase it well. I meant if you know of any software<br>
> project page (yours or not) that you particularly like and from which<br>
> we could borrow some ideas :)<br>
<br>
</div><a href="http://info-beamer.org/" target="_blank">http://info-beamer.org/</a> looks nice, but feel free do to what you like.<br></blockquote><div><br></div><div style>Got it. I'll get back to the list later with a proposal which we can iterate on.</div>

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

</div></div></div>