Re: Dashboard?

["Joe Shaw" <joe joeshaw org>]

Hi Nils,

Welcome back!  Nice to see you again. :)

On 11/21/07, Nils Erik Svangård <nilserik gmail com> wrote:
> * libdashboard - Or as its better known, a C library that generates
> valid, parseable clues. This is not only critical since most plugin
> authors aren't going to want to spend the time validating that mono
> can deserialize all their XML. But because we can generate bindings
> for most every other language once we have them in C.

I actually think this is the wrong thing to do.  This is something we
explicitly avoided the first time around with Dashboard, and was a
large reason why we were able to instrument as many applications as we
did.

The problem with creating a library and making people use it is that
it introduces a new library dependency.  That's extra work for the
maintainers of the software, developers, and packagers of the
software, and for something as immature and experimental as Dashboard,
they simply won't do it.

So the way we did it originally was to include a fully self-contained
.c file which people would #include into their project, and all the
functionality could be included as a simple patch.

Ok, that was a long setup, but I think it might even be easier today:
with inotify, we don't even really need a programmatic IPC mechanism
-- we can just drop XML files into a watched directory and the
Dashboard can pick them up automatically.  For projects which already
use D-Bus, that's a viable alternative as well (but not the sole one
-- no adding D-Bus to projects which don't already use it, because,
again, added dependencies).

> * Real Bug/Performance Testing/Fixing - This is a huge one, Dashboard
> is still pre-alpha, and mostly proof of concept. While the code base
> could be brought up to production level, it needs tons of cleanup.

The amount of Dashboard code there is sufficiently small enough that
it can either be used as a starting point, as a good chunk of
reference code to look at, or redone completely.

I would strongly encourage unit and automated regression tests for
this sort of thing; it's something we haven't been particularly good
about in Beagle and it has clearly hurt us.

> Is there more stuff that have to be done?

Well, there isn't a UI for it, so that's a big amount of work. :)
It's unclear to me exactly how to present results most usefully to
users.  The decaying method we had before was a fairly simplistic way
of doing it.  Some machine learning would probably be pretty useful
here.

> Is anybody working on dashboard?

Sadly, I don't think so.  There were some patches sent to the list,
and I believe some were committed, but nobody has really taken
ownership of the project, which is what it really needs at this point.

Joe