>> I still don't see how that differs from a "view."
>
> To me, a view is formed by a restructuring or simplification of the
> subject material that is *externally applied* to the material. In
> aspect-oriented modelling, the structure is built into the material.
> A variable/value applies to an object *and* pertains to an aspect,
> intrinsically, not because some viewer wants to see it that way.

So, a ToDo item has a Period in which you want to work on it; and a
period would be data from an Agenda aspect, really.

Moreover, RepetitiveAppointments for the Agenda have very nasty habits
(cancelled meeting, different time or location, etc, etc). It is very
hard to capture that in 'just' a view. I'd even say I want more views:
one view with all the effective appointments, of course, but also of all
cancelled appointments (to un-cancel them, for instance).

In ruby duck-typing style, I wouldn't care about what is visible and
not, so views and '(groups of) properties' are less strictly separated.
That may not be so good for the current discussion.

[unlike contact, todo, notes and other types of info, I'm not sure
Tycho is suitable for agenda entries; opinions? birthdays from contacts,
deadlines from ToDos should make it to the agenda. perhaps an external
link for this very special type of information?]

>> Then would you use a database for that or not? The columns of a table
>> are typically fixed and unvarying. (That's why my current code uses a
>> serialized hash for the user-defined metadata -- the field names are
>> not known in advance.)
>
> Yes, it's a problem to map aspect-oriented data to a database for this
> reason. I started a project in 1987 to build an aspect-oriented database
> to solve this, but I never finished it. So now I'm where you are, having
> to choose between:
> * using a database with a meta-schema - so you can't "see" the true
>    schema :-(,
> * mapping the aspect model to a relational schema - somewhat inflexible,
> * abandoning the idea of using a transactional store at all, and just
>    stashing the data into a data file (like XML, YAML, etc).
> Not a good set of alternatives, I admit.

Hm. I've played with the last method, in the past. Had to split up the
agenda in history-per-year and future data, 'coz loading on iPAQ became
slow.

Haven't thought of anything better, yet. rdbms
maintainers build another index when stuff is 'too slow'. I don't think
that's very scalable, especially for a handheld. My pre-filtering for
the agenda is similar, tho (and doesn't work for a contacts-list).

+--- Kero ------------------------- kero@chello@nl ---+
|  all the meaningless and empty words I spoke        |
|                       Promises -- The Cranberries   |
+--- M38c --- http://members.chello.nl/k.vangelder ---+