Re: Proposing Tracker for inclusion into GNOME 2.18
- From: Federico Mena Quintero <federico ximian com>
- To: Nick Murtagh <nickm go2 ie>
- Cc: Mariano Suárez-Alvarez <msuarezalvarez arnet com ar>, kde-core-devel kde org, desktop-devel-list gnome org, Jamie McCracken <jamiemcc blueyonder co uk>
- Subject: Re: Proposing Tracker for inclusion into GNOME 2.18
- Date: Mon, 23 Oct 2006 20:08:09 -0500
On Mon, 2006-10-23 at 22:15 +0100, Nick Murtagh wrote:
> Mariano Suárez-Alvarez wrote:
> > I have no idea what ‘first class object database’ means, so please
> > explain what you mean by that if you need to.
>
> http://en.wikipedia.org/wiki/First_class_%28computing%29
That's database jargon, and it's completely uninteresting to users.
Think of "first-class" with the same usage in which you would say "the
Scheme language provides first-class functions and environments". Just
like you can create integers, pass them to functions, and return them
from functions, in Scheme you can also create functions, pass them to
other functions, and return them from functions. Same thing with
environments [what they are in Scheme's terms is not interesting for
this discussion]. The idea is that an object is first-class if you can
create it, manipulate it, and embed it just like any of the most
fundamental objects in your language.
In GNOME we've been throwing the term "first-class objects" since GUADEC
2004 in Kristiansand. The idea is that users have different kinds of
data, roughly grouped as "documents", "contacts", "mails",
"appointments", "bundles", etc., but it is very difficult to combine
data of different types, or associate that data together.
For example, it's hard to "send a contact" to someone without explicit
support in the applications. You may have some luck in dragging a
contact out of your addressbook into your mail program; ideally, the
mail should get a vCard attachment. On the recipient's side, you can
often add a vCard attachment to your addressbook reasonably easily.
However, mail and contacts are so closely related that the programs that
handle them often have explicit hooks for each other's data.
It's very rare that you can do things like the following. You get a
vCard attachment. You want to drag that contact and drop it to your
desktop: "I'll put this contact here so that I'll remember to call him
later". How would this work? Do you want the file manager to see that
it is being dragged something of type "text/vcard" (or whatever the
right MIME type is), and then run some ad-hoc code to render a contact
on your desktop? Or should it call out to the addressbook to render the
contact? Or should it just display a generic "vCard" icon, and hope
that you have the right MIME-to-program associations for when you
double-click the icon later?
I have this stone-age PDA that lets you create notes (a General Magic
DataRover). Then it lets you create little drawings. Then you can drag
your drawings into the notes, just like that, and place them anywhere.
You can also drag contacts into the notes. You can link the notes into
your calendar appointments. The Right Thing(tm) just happens when you
manipulate these objects into others. It's hard to define just what
happens in every case, but when you see it happen, it feels very
comfortable and natural.
The idea behind "first-class objects" is that you get that kind of
flexibility. I have no idea what the APIs for that PDA looked like. I
don't know if the notes/drawing/contacts/calendar programs in it were
hardcoded to accept each other's data seamlessly, or if their APIs were
flexible and pluggable enough that you could do this with any kind of
data.
Defining "first-class objects" is very hard in GNOME's context, because
we are not sure what kinds of objects we want to have, nor what kinds of
actions we want to be able to perform among them. It would be very
productive to do some archaeology for the DataRover's APIs and history.
Take a look at OpenCroquet as well. It is mightily pluggable and
flexible, and data of different types just seems to flow smoothly from
program to program. I'm sure we could use some interesting ideas from
there.
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]