Refactoring Tycho API - Opinions wanted

[Hal Fulton]

I've been revisiting my favorite Ruby project in the past
few weeks.

Basically this is my approach:

1. Start with the API, test it heavily, worry about GUI later
2. Learn from my mistakes over the last two iterations
3. Use KirbyBase for storage (for now), as it is simple, Rubyish,
and runs everywhere

For those totally unfamiliar with Tycho, see the main page
(which does need to be updated):
http://tycho.rubyforge.org

See also my slides from RubyConf2004 (similarly out of date):
http://rubyhacker.com/tycho/slides/

In short: Tycho is a tool for managing random information
in the form of "notes" arranged in a hierarchy of "topics."
For purposes of scripting both inside and outside the tool,
a rich Ruby API is planned.

Example uses of API:
- grab certain RSS feeds and store them
- scan the latest 'ri' data and store it
- write alternate interfaces (web, etc.)
- perform ad hoc analyses of all content


====================================================
NOTE: My latest scribblings on the API are really
where I'd like feedback at the moment.

See: http://rubyhacker.com/tycho/apinotes.txt
====================================================


Disclaimer: Yes, I use the exclamation point in a somewhat
unconventional way -- it indicates a recursive search
(arguably "more dangerous" than a simple search). You're
welcome to comment on that, but let's not start a whole
subthread to debate it.

Obviously you're free to say things like "I just don't
get it." I'm hoping however that you *will* "get it" and
will have some high-level comments about the API.


Thanks,
Hal

 

[James Britt]

I've been revisiting my favorite Ruby project in the past
few weeks.

Basically this is my approach:

1. Start with the API, test it heavily, worry about GUI later
2. Learn from my mistakes over the last two iterations
3. Use KirbyBase for storage (for now), as it is simple, Rubyish,
and runs everywhere
...

Obviously you're free to say things like "I just don't
get it." I'm hoping however that you *will* "get it" and
will have some high-level comments about the API.

My comment is not on the API (which I confess I have not the time right
now to look at) but at your approach. Is this meant primarily for people
end-users, or code end-users?

I ask because if people are the main target then perhaps the UI should
be driving the API, or at least the feature set (and through that the API).



James



--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[rubyhacker]

My comment is not on the API (which I confess I have not the time right
now to look at) but at your approach. Is this meant primarily for people
end-users, or code end-users?

I ask because if people are the main target then perhaps the UI should
be driving the API, or at least the feature set (and through that the API).

That's a very reasonable comment and a fair question.

The API serves a dual purpose.

First of all, it does indeed make Tycho scriptable both internally and
externally. So in that sense it is intended for people (and is a kind
of user interface itself like any other API).

The second purpose is to encapsulate or package all the operations that

might be performed programmatically on the data. This allows separate
testing and debugging of these features. One problem I ran into before
was that I was trying to work on the GUI and the API at the same time.
They became entangled in my mind and thus in the code.

My thought is that the scripting API would probably be a superset of
what the GUI itself needs. At any rate, the overall behavior of the GUI
is fairly well thought-out and will not change drastically. There will
certainly be details to iron out -- arrangement of menus, ordering of
items, what if I right-click here, etc.


Hal

 

[Kero]

1. Start with the API, test it heavily, worry about GUI later

2. Learn from my mistakes over the last two iterations
3. Use KirbyBase for storage (for now), as it is simple, Rubyish,
and runs everywhere

wil have to check that, I'm using ruby itself, running eval(buf)
to load a database. Faster than xml or yaml stuff

In short: Tycho is a tool for managing random information
in the form of "notes" arranged in a hierarchy of "topics."

Could be addresses? Which is what I coded in the past few days.
with a simple CLI interface, snippet below, no API, yet.
And I don't want to stop at mere contacts/addresses.

http://handhelds.org/cgi-bin/cvsweb.cgi/rb-pim/

common/hash.rb
common/array.rb
address/ # almost all files

Example uses of API:
- grab certain RSS feeds and store them
- scan the latest 'ri' data and store it
- write alternate interfaces (web, etc.)

Yeah, would be nice. iPAQ doesn't work for a CLI.

- perform ad hoc analyses of all content

If you wish

====================================================
NOTE: My latest scribblings on the API are really
where I'd like feedback at the moment.

See: http://rubyhacker.com/tycho/apinotes.txt
====================================================

app.find_note vs app.find_topic vs topic.find_note
is this distinction necessary? isn't it 'just' an additional
filter? (you probably have a reason for this, I'd like to know)

Possible future standard metadata uses:

Which user/instance of the program initiated this add/change/delete?
Make topics or notes read-only?
Protect topics/notes from being deleted?
Allow a note to refer to an external file rather than storing the data?
Sure, why not? I can give an URI, either way. So why not accept it and
be able to show it (start another program to show it). This could
include email addresses to start an email client; phone numbers to dial
someone (for a smartphone, or using
whats-the-open-alternative-for-skype-again) and implicitely cross
linking in the notes themselves. a note saying "Ask Hal about Tycho"
should enable me to search the contact of a certain "Hal" and other notes
about "tycho". (myeah, that's working with the content, not the
metadata.)

Allow hidden topics/notes?
What for? (or, hidden for whom?)
Allow password protection or security on topics/notes?
don't we have multi-user computers for that? or private computers
(handhelds, phones)?

What I'm also interested in, is exporting a set of notes or parts of
notes to other files (specifically, I want to print addresses of
my contacts; but maybe that's too specific for a general function).

I don't understand the implementation notes about dir001/dir001 vs
1:13:135; where do the numbers come from? (what key?)

Obviously you're free to say things like "I just don't
get it." I'm hoping however that you *will* "get it" and
will have some high-level comments about the API.

Dunno whether I "get it". Part of it, at least
See some 'find' CLI session example below.

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

## PIM/address> search K
1: Kero van Gelder
2: Mr. X (with a capital k somewhere else in his record)
## PIM/address> show 1
name: Kero van Gelder
born: 30 Aug 1974
[locations: old-home2, dummy, old-home, home, work]
## PIM/address> location dummy
address: For demo purposes only
code:
city:
phone:
mobile: 06-beepbeep
email: kero@chello@nl
url: http://chmeee.dyndns.org/
## PIM/address>

 

[rubyhacker]

Could be addresses? Which is what I coded in the past few days.

with a simple CLI interface, snippet below, no API, yet.
And I don't want to stop at mere contacts/addresses.

Sure, could be anything -- addresses, URLs, quotes, code snippets,
lists, etc.

http://handhelds.org/cgi-bin/cvsweb.cgi/rb-pim/

You're eventually targeting the handheld? Coolness.

I also want to integrate outside apps with Tycho. Let them share
data and let Tycho be a browswer for all of them.

app.find_note vs app.find_topic vs topic.find_note
this distinction necessary? isn't it 'just' an additional
lter? (you probably have a reason for this, I'd like to know)

The distinction between notes and topics is necessary. Think of
the Unix find, how it can do "-type d" or "-type f" for an analogy.

There is some redundancy in the API. Most of it is just for
convenience or readability or conciseness.

Allow a note to refer to an external file rather than storing the data?
Sure, why not? I can give an URI, either way. So why not accept it
and
be able to show it (start another program to show it). This could
include email addresses to start an email client; phone numbers to > dial
someone (for a smartphone, or using
whats-the-open-alternative-for­-skype-again)

I'm uncertain how much mind-reading I want the app to do. Someone
once looked at it and said, "Oh, it's a file manager."
No, it isn't. But I do like the idea of being able to refer to
files and launch (various) applications on those files with single
button presses. Maybe even add a feature that would import whole
directories into topics, and add action buttons for each file
based on its type (and the apps available on the system).

and implicitely cross
linking in the notes themselves. a note saying "Ask Hal about
Tycho"
should enable me to search the contact of a certain "Hal" and other
notes
about "tycho". (myeah, that's working with the content, not the
metadata.)

Maybe optionally make certain terms clickable in the GUI on a per-
note per-term basis.

Allow hidden topics/notes?
What for? (or, hidden for whom?)

Possibly just to get them out of the way (like dot-files in Unix).
Possibly to disallow copying them when info is published (e.g.
on the web) or shared (with another person running his own app).

Allow password protection or security on topics/notes?
don't we have multi-user computers for that? or private computers
(handhelds, phones)?

It might conceivably be run in a "repository-like" fashion, i.e.,
multiple remote users. Could be "readable" by everyone, "writable"
only when logged in, or whatever.

What I'm also interested in, is exporting a set of notes or parts of
notes to other files (specifically, I want to print addresses of
my contacts; but maybe that's too specific for a general function).

That is an example of where you would write a little script using the
API. The script itself could be stored in a note, perhaps with a "Run
me"
button or the equivalent. It could then find all its siblings and treat
them as data.

I don't understand the implementation notes about dir001/dir001 vs
1:13:135; where do the numbers come from? (what key?)

The numbers are meaningless, assigned sequentially within each level.
"1" is root; "1:1" would be the first topic under root and "1.1" would
be
the first note under root. (They may be sorted or rearranged in many
different ways when they are presented, of course.)

Dunno whether I "get it". Part of it, at least

The version on rubyforge *should* work -- it's just old and not full-
featured by any means. But you can do searching and sorting and
add/delete notes and such. And it comes with several hundred
notes already -- all the 'ri' data, a snapshot of rubyforge, and the
TOC
for _The Ruby Way_. Also a few little demo notes.

See some 'find' CLI session example below.

This is the sort of thing Tycho would be good for, *except* that you
would either have to enter the addresses free-form or wait for some
kind of "template" or "field-oriented" feature to be added (which is on
my list).


Hal

 

[Clifford Heath]

In short: Tycho is a tool for managing random information
in the form of "notes" arranged in a hierarchy of "topics."

Ok Hal, I've had a read of your API. I created an ORM model of it
in fact, using VisioModeler. That's ORM as in Object Role Model.
The reason I've taken an interest in this is because I believe that
such a tool can benefit strongly from an aspect-oriented data model,
more on that later.

1. Start with the API, test it heavily, worry about GUI later

Good move not starting on the GUI, but you need to start even further
back, with a conceptual data model. The API is then a simple consequence
of the data model.

NOTE: My latest scribblings on the API are really
where I'd like feedback at the moment.

You have a few bits of mixed terminology or terms used only once.
For example:
* I assume that "name" and "title" are the same thing?
* You also use the word "key" - again, is this "title" or
is it a path in the data store?
* What's the significance of the "current" topic - is that just a
presentation thing or does it affect searching? No other function
seems to indicate that the current topic is relevant.
* What's the effect of "load"ing a topic of note?

Functionality questions:
* When you change the root topic of an app, what happens to all the
now unreachable topics and notes? Is the change persistent? Perhaps
you could replace this problematic operation with a simple "flip
parent and child" operation?
* It isn't clear whether find_topic searches content or just titles.
* It seems that topics and notes differ only in that notes have content,
which requires a different presentation, and in whether the metadata
inherits (BTW, this isn't inheritance I believe, but propagation down
the tree - is that right?).
Why bother with the two things - instead you could simply load all
items having no content as your tree.

Aspect orientation suggestion:
Your model has a number of different kinds of data value associated
with each note or topic. For example, you have info on date/time and
number of times accessed, modified, etc. You have GUI variables. You
have sorting and searching (keywords).

If you regard each item (topic/note) as having values for variables,
you can model the variables as pertaining to a relevant (meta-)topic.
So for example, you could have a Presentation topic, which contains a
Note sub-topic. The variables whose values define the presentation of
a note "belong" to the Note class, but "pertain" to the
Presentation/Note subtopic. I also allow Items to pertain to other
items.

In this way you provide for an arbitrary number of kinds of metadata,
while the model actually has very little actual *meta*data. The only
metadata you need is the "Item" class(es) and the Variable class(es).

Item has a title string, a parent Item, a superclass Item (e.g. Topic,
Note), an Item to which it "pertains" (which will often be its parent),
subitems, optional Variables, and optional values (for its variables
and for inherited ones).

Variable is also an item (each has the same), but its subclasses define
sub-Variables, for example "max-length" for a string, etc.

The API should allow fetching all values (including inherited and
propagated) of an item which *pertain to* the aspect of interest. So
for example the GUI will fetch values of all variables of items which
pertain to the Presentation topic. The searcher will fetch values of
different variables, and the object manager will access and update
values pertaining to access and modification times and counts. You can
also store user information (values for an item, and subitems) into
multiple aspects in the same way. It creates some interesting search
algorithms, but is a very powerful way to separate different kinds of
data and metadata.

Let me know if I haven't explained this adequately.

Clifford Heath.

 

[Hal Fulton]

Ok Hal, I've had a read of your API. I created an ORM model of it
in fact, using VisioModeler. That's ORM as in Object Role Model.
The reason I've taken an interest in this is because I believe that
such a tool can benefit strongly from an aspect-oriented data model,
more on that later.

Wow, I'm speechless. I didn't expect anyone to pay such close attention.

Good move not starting on the GUI, but you need to start even further
back, with a conceptual data model. The API is then a simple consequence
of the data model.

That may be true, but if the API is a "simple consequence," I would guess
that the data model is pretty heavily specified.

You have a few bits of mixed terminology or terms used only once.
For example:
* I assume that "name" and "title" are the same thing?
Yes.

* You also use the word "key" - again, is this "title" or
is it a path in the data store?

The key is a unique string assigned to each item. It serves as a
literal key into each database table. See the bottom of the file.

* What's the significance of the "current" topic - is that just a
presentation thing or does it affect searching? No other function
seems to indicate that the current topic is relevant.

I'm undecided on that issue. It certainly affects presentation, but
it's not obvious to me whether the notion of a "current" topic makes
certain operations easier. I *think* it does.

* What's the effect of "load"ing a topic of note?

Did you mean "topic OR note"? A "load" simply references all the tables
needed to get the "pieces" of an object, then assembles them into a
"real" Ruby object (of class Note or Topic) and returns it.

Functionality questions:
* When you change the root topic of an app, what happens to all the
now unreachable topics and notes? Is the change persistent? Perhaps
you could replace this problematic operation with a simple "flip
parent and child" operation?

That's also unclear to me at this time. I was thinking along the lines
of a Unix "chroot" operation -- "pretend" that this subset of the tree
is the whole tree for now. Not sure this concept is useful.

* It isn't clear whether find_topic searches content or just titles.

In the "simple" form it searches only titles. In the block form, you can
access any or all content or metadata for purposes of searching, but you
do it explicitly (by analogy with Enumerable#find).

* It seems that topics and notes differ only in that notes have content,
which requires a different presentation, and in whether the metadata
inherits

That may be true, but it hurts my head to think of the terminal and non-
terminal nodes as being the same thing. It's a very CS approach, of course,
but it doesn't fit my mental model.

(BTW, this isn't inheritance I believe, but propagation down
the tree - is that right?).

I'm not sure what you mean. There are probably good reasons not to call it
inheritance. But it's not simple cascading, i.e. doesn't affect siblings.

Why bother with the two things - instead you could simply load all
items having no content as your tree.

Probably is doable, but again, doesn't fit the way I think.

Aspect orientation suggestion:
Your model has a number of different kinds of data value associated
with each note or topic. For example, you have info on date/time and
number of times accessed, modified, etc. You have GUI variables. You
have sorting and searching (keywords).

If you regard each item (topic/note) as having values for variables,
you can model the variables as pertaining to a relevant (meta-)topic.
So for example, you could have a Presentation topic, which contains a
Note sub-topic. The variables whose values define the presentation of
a note "belong" to the Note class, but "pertain" to the
Presentation/Note subtopic. I also allow Items to pertain to other
items.

It sounds like you're talking about multiple "views" of the data, is
that correct?

In this way you provide for an arbitrary number of kinds of metadata,
while the model actually has very little actual *meta*data. The only
metadata you need is the "Item" class(es) and the Variable class(es).

Item has a title string, a parent Item, a superclass Item (e.g. Topic,
Note), an Item to which it "pertains" (which will often be its parent),
subitems, optional Variables, and optional values (for its variables
and for inherited ones).

Variable is also an item (each has the same), but its subclasses define
sub-Variables, for example "max-length" for a string, etc.

I'm halfway following this, though it's confusing. How would you
propose to store all this?

The API should allow fetching all values (including inherited and
propagated) of an item which *pertain to* the aspect of interest. So
for example the GUI will fetch values of all variables of items which
pertain to the Presentation topic. The searcher will fetch values of
different variables, and the object manager will access and update
values pertaining to access and modification times and counts. You can
also store user information (values for an item, and subitems) into
multiple aspects in the same way. It creates some interesting search
algorithms, but is a very powerful way to separate different kinds of
data and metadata.

It does sound powerful, but I wonder 1) would it require a full-fledged
database? and 2) wouldn't it require an awful lot of disk access to
store things in a "scattered" format?


Thanks much,

Hal

 

[Clifford Heath]

That may be true, but if the API is a "simple consequence," I would guess
that the data model is pretty heavily specified.

Well, a conceptual model describes a state space, and should contain
the business rules that restrict legal states in that space. ER
models are more limited than ORM models in their ability to represent
the rules.
By describing what can exist, the API flows as "how to create,
search, update and delete" every state that can exist. It's
always simple to design an API for a good conceptual model.

The key is a unique string assigned to each item.

Ok. This is the hierarchical thing. In some DBMSs it would be a simple
numeric RID (Record ID), but that doesn't assist in subtree searches.
If you guarantee that for any object, a child-ID will never be re-used,
you create a useful unique-for-all-time hierarchical ID.

Did you mean "topic OR note"?
Yes.

That's also unclear to me at this time. I was thinking along the lines
of a Unix "chroot" operation -- "pretend" that this subset of the tree
is the whole tree for now. Not sure this concept is useful.

If it's not persistent, I'd leave it out. Any search operation should be
able to take a context object and function from that. You might also
consider a "new window from here" type operation that creates a new view
of the topic tree from that point down. But this is just a presentation
thing.

For persistent tree changes, the "flip parent and child" is a useful op.
If the new parent is to "adopt" all the children of the old parent,
that will change values propagated into the children.

I'm not sure what you mean. There are probably good reasons not to call it
inheritance. But it's not simple cascading, i.e. doesn't affect siblings.

A sub-topic, or a note in a topic, which uses a value defined by
its parent object, is experiencing value propagation rather than
inheritance, since the child isn't derived from the parent through
inheritance, but contained in a parent-child relationship.

I note that you don't make any mention of actual inheritance. That
simplifies things, but don't confuse the parant-child relationship
with an inheritance one.

It sounds like you're talking about multiple "views" of the data, is
that correct?

It does give you that capability, but it's more than that. Essentially
an observer has a topic of interest (what I call an aspect), and when
looking at or for a target object, they see only those attributes (and
children, if that's implemented) which are relevant to that topic.

I'm halfway following this, though it's confusing. How would you
propose to store all this?

I've been through many models for that, and the simplest is to just
store each child item (a reference to a sub-topic or note, a value
for a variable) with its "pertains-to" value, in a single place,
serialised with the object, regardless of its relevance (aspect).

It does sound powerful, but I wonder 1) would it require a full-fledged
database? and 2) wouldn't it require an awful lot of disk access to
store things in a "scattered" format?

No. There's no *need* to scatter things. You could label an aspect such
that all items which pertain to it are out-of-line (not stored directly
in the parent object), which allows control of clustering, but it's not
necessary. For example, you could choose to store all GUI layout
values away from the objects to which they pertain... but it's not
needed in a simple tool.

The important thing is to allow the *viewer* to see only the data which
are relevant to their search, without having to create "metadata"
categories to store other things (like layout info etc).

The key observation of aspect-oriented modelling is that for any
subject, there is a potentially unlimited number of categories of
descriptive information - each category being a different aspect.
I use the term "facet" to describe the facts for an object which
pertain to a given aspect. For example color is an aspect, green
is the color facet of "grass"). You can think of a facet as being
like a programming-language "interface" - one object may have any
number of interfaces. This argues that though the database must
know *all* the attributes of an object, any given API for that
object must assume that the object has more attributes than the API
shows - that is, it only ever returns interfaces. Any query searches
an aspect, and only relevent facets of the result objects will be
visible without further searching.

Clifford Heath.

 

[Lothar Scholz]

Hello Clifford,

CH> Good move not starting on the GUI, but you need to start even further
CH> back, with a conceptual data model. The API is then a simple consequence
CH> of the data model.

No i don't agree here. The UI and the way to present data, has such a huge
influence that it must be considered in every development cycle.

Here we are talking about use cases not about a button here or there.
And adding a user interface on top of a existing data model allways
result in too much restrictions.

Tycho is an application where the user interface is the key to
success.

And by the way, Hal, the knock out criterium for the first tycho
version was the non available multi dimensional classification. When i
download such tools and only see a simple tree, i delete the
application within the first five minutes - no matter what else is
there.

 

[Clifford Heath]

CH> Good move not starting on the GUI, but you need to start even further
CH> back, with a conceptual data model. The API is then a simple consequence
CH> of the data model.
No i don't agree here. The UI and the way to present data, has such a huge
influence that it must be considered in every development cycle.

Yes, and no. You are speaking from the biassed perspective of the kind
of data models that databases implement directly - basically ER models.
Those are often badly constructed, because the ER model isn't rich
enough to catch the conceptual model, and performance often demands
that salient elements must be compromised even when they could be
represented in the ER model. The other problem with ER models tends to
be that the object modellers get to drive the process, and then go to
the DBA's and say "here's our data, find a way to stash that". Object
models are commonly even worse than ER models at catching the conceptual
structure.

Conceptual models on the other hand, always reflect the flow of a good
user interface, and vice versa. This is for the simple reason that they
represent the mind map of the user. Every action in any UI is one or
more steps along the arcs of the conceptual model. Whether the designer
ever wrote the conceptual model down or not, the arcs are there in the
semantic space, and so are the objects they join.

And adding a user interface on top of a existing data model allways
result in too much restrictions.

No. Adding a user interface on top of a data model *that does not
reflect the conceptual model* does that. Learn to construct proper
conceptual models, then to map them to ER models and object without
forgetting the original conceptual model, and you'll find it all
comes out beautifully, every time.

Read more about Object Role Modelling at www.orm.net and related
sites. I've been following Terry Halpin's work for 18+ years now,
and he's an excellent fellow, even if his company did get acquired
first by Visio then Microsoft, where he now is. There's a good video
introduction to ORM by him and otherson one of the Microsoft DotNet
sites, check it out, very enlightening.

And by the way, Hal, the knock out criterium for the first tycho
version was the non available multi dimensional classification. When i
download such tools and only see a simple tree,...

My description of aspect-oriented modelling is an attempt to address
exactly that problem. It isn't covered by any formal literature, AFAIK.

Clifford Heath.

 

[rubyhacker]

Ok. This is the hierarchical thing. In some DBMSs it would be a simple

numeric RID (Record ID), but that doesn't assist in subtree searches.
If you guarantee that for any object, a child-ID will never be re-used,
you create a useful unique-for-all-time hierarchical ID.

Hmm. I hadn't thought of guaranteeing unique-for-all-time (i.e. maybe
not
across a database cleanup or something), but it's a thought.

If it's not persistent, I'd leave it out. Any search operation should be
able to take a context object and function from that.

Yeah, my approach will likely be "leave it out and put it in only if I
see a compelling reason."

For persistent tree changes, the "flip parent and child" is a useful op.

Agreed. I haven't sketched out such operations yet.

A sub-topic, or a note in a topic, which uses a value defined by
its parent object, is experiencing value propagation rather than
inheritance, since the child isn't derived from the parent through
inheritance, but contained in a parent-child relationship.

I note that you don't make any mention of actual inheritance. That
simplifies things, but don't confuse the parant-child relationship
with an inheritance one.

I wasn't using this in a strict OOP sense. After all, the word
"inheritance"
does predate computers by many centuries.

True, there's no subclassing going on. But if the child gets something
from the parent as a direct consequence of the parent-child
relationship,
that's a kind of inheritance. Just ask Gregor Mendel.

But I'm content with the term "propagation" as well.

It does give you that capability, but it's more than that. Essentially
an observer has a topic of interest (what I call an aspect), and when
looking at or for a target object, they see only those attributes (and
children, if that's implemented) which are relevant to that topic.

I still don't see how that differs from a "view."

I've been through many models for that, and the simplest is to just
store each child item (a reference to a sub-topic or note, a value
for a variable) with its "pertains-to" value, in a single place,
serialised with the object, regardless of its relevance (aspect).

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.)

No. There's no *need* to scatter things. You could label an aspect such
that all items which pertain to it are out-of-line (not stored directly
in the parent object), which allows control of clustering, but it's not
necessary. For example, you could choose to store all GUI layout
values away from the objects to which they pertain... but it's not
needed in a simple tool.

OK, I think part of my problem here is that I don't know much about
AOP.
Is that the kind of "aspect" you mean?

I am greatly appreciative of your interest in this, but I would want to
know how far your interest extends. No offense, but if I were going to
throw away my own model in favor of one I don't yet understand, I'd
need to know that you were going to contribute significant time and
code
to the project.

If you wish, I'll send you my latest code offline.


Hal

 

[rubyhacker]

And by the way, Hal, the knock out criterium for the first tycho

version was the non available multi dimensional classification. When
i download such tools and only see a simple tree, i delete the
application within the first five minutes - no matter what else is
there.

Different people may have different concepts of what the "knockout
criterion" is.

Anyway, sorry if I misled you. The major and minor version numbers
are zeroes for very good reason -- less than ten percent of the planned
functionality is present.


Cheers,
Hal

 

[Kero]

http://handhelds.org/cgi-bin/cvsweb.cgi/rb-pim/

You're eventually targeting the handheld? Coolness.

I was targeting the iPAQ before; but UI kept bothering me.
It's just that my contacts list need better maintainability and
flexibility that I picked up the topic again. and then you interfered

The distinction between notes and topics is necessary. Think of
the Unix find, how it can do "-type d" or "-type f" for an analogy.

does it?
I'll accept it as classification; notes should be able to fit more than
one class/topic, I suppose?
(does this match the aspects from Clifford?)

The version on rubyforge *should* work -- it's just old and not full-
featured by any means. But you can do searching and sorting and
add/delete notes and such. And it comes with several hundred
notes already -- all the 'ri' data, a snapshot of rubyforge, and the
TOC
for _The Ruby Way_. Also a few little demo notes.

trying to get foxruby working now...

This is the sort of thing Tycho would be good for, *except* that you
would either have to enter the addresses free-form or wait for some
kind of "template" or "field-oriented" feature to be added (which is on
my list).

some things are free form. I play a trick so address/code/city in a
Location are 'always there', but arbitrary key/value pairs can be added
(you have always funny info about some persons that won't be in any
fixed list of keys (attributes)).

PS: as coincidence, I saw "Lost in Translation" last Tuesday, which
features on one of your screenshots

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

 

[Clifford Heath]

Hmm. I hadn't thought of guaranteeing unique-for-all-time

The benefit is that you can have references from one Tycho database
to another, and where the databases are separately updated, the
references will still be valid as long as the referenced object
still exists. Likewise for any internal references, you don't have
to go searching to update and delete them when the referenced object
gets changed.

I wasn't using this in a strict OOP sense. After all, the word
"inheritance" does predate computers by many centuries.

Understand. It's just that parent-child is a common description
of an aggregation relationship (no inheritance), and "inheritance"
is applied to classification hierarchies (quite unlike the parent-
child relationships the term implies). Typical non-intuitive semantic
disjunctions. Computer scientists seem to specialize in fouling up
language this way :-(.

But I'm content with the term "propagation" as well.

The reason I use propagation is that I don't know of any language
where *values* get inherited. It's always traits - variables and
methods. My Aspect Definition Language has value inheritance, but
I restrict myself to using inheritance in the bogus O-O way,
applying it to the classification hierarchy as others do. That
leaves me unable to use the same term where a child uses a value
defined by its parent, so I use the term "propagation" for that .

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.

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.

OK, I think part of my problem here is that I don't know much about
AOP. Is that the kind of "aspect" you mean?

It's related, but AOP is not it. In fact I think AOP is pretty
mis-guided. It addresses real problems, but in the wrong way.
Aspect-oriented modelling is my solution to that.

I am greatly appreciative of your interest in this, but I would want to
know how far your interest extends. No offense, but if I were going to
throw away my own model in favor of one I don't yet understand, I'd
need to know that you were going to contribute significant time and
code to the project.

Understand. I think you'll find that to adopt some of the ideas I'm
suggesting is quite simple and doesn't require much change from what
you were going to do anyway. At present I can't say whether I'll be
able to contribute to Tycho, because I'm awaiting the go-ahead (in the
form of an IP disclaimer from my employer) on a much more ambitious
project. If that comes through, I'll be able to demonstrate what I'm
on about, but not through Tycho.

 

[Joel VanderWerf]

Clifford Heath wrote:
...

The reason I use propagation is that I don't know of any language
where *values* get inherited. It's always traits - variables and
methods. My Aspect Definition Language has value inheritance, but
I restrict myself to using inheritance in the bogus O-O way,
applying it to the classification hierarchy as others do. That
leaves me unable to use the same term where a child uses a value
defined by its parent, so I use the term "propagation" for that .

ADL sounds interesting, but google doesn't know much about it. Is it
published, or can you give us some hints or examples?

I'm asking because I've written a language for inheritance of values,
and used it as the specification language for simulations. It may be
completely irrelevant to ADL, but I'm still curious.

 

[Hal Fulton]

I'll accept it as classification; notes should be able to fit more than
one class/topic, I suppose?

At the moment, I'm not sure how that will work. There will be different
views available, but I think these will be different views of the entire
tree. There won't be more than one topic for a note.

trying to get foxruby working now...

I feel your pain. Once it works, it works pretty well.

PS: as coincidence, I saw "Lost in Translation" last Tuesday, which
features on one of your screenshots

Ha, I love that movie.

"Why do they switch around their Ls and Rs here?"
"Just for yucks."


Hal

 

[Kero]

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?]

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 ---+

 

[Clifford Heath]

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.

Exactly, good example. I would have a Scheduling aspect (Agenda is a
sub-aspect of that), and I would have an Activities aspect. The ToDo
item then crosses both aspects.

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.

True. The important thing for this is that the facets of an object
cannot change the nature of the base object. They can change the way
it behaves within the boundaries of its public interface, but it should
still *be* what it claims to be. I realise this is a question of static
vs dynamic typing, and I'm entirely sold on duck typing, but it isn't
a discussion I want to re-open here.

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.

Yes, that's the problem with large serial files - you can't update
without loading the whole file.

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.

It's also the wrong answer in many cases, as it makes update slower.
You can't design good databases unless you understand how queries are
processed. I still have a dream one day of taking the transactional core
of a DMBS, for example "Shore", and building a truly aspect-oriented
database on it. When I tackled this in 1987, there were no DBMS
available in source, so I had to start from scratch. I failed, because
key techniques (like KVL etc) were unpublished trade secrets of the
DBMS vendors at that time.

Clifford Heath.

 

[Hal Fulton]

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.

Actually, let me stop right here and say that Tycho is not intended
for to-do or appointment types of things.

I do have a different app I've been playing with for that (a web-based
one) and might look at synergy between them later. But right now they
are both too immature. In fact, Kronos has been rebugged so much that
even I can't use it at the moment.


Hal

 

[Clifford Heath]

ADL sounds interesting, but google doesn't know much about it. Is it
published, or can you give us some hints or examples?

No. I hadn't published specs before. The only document I have is a
little dated, but you'll probably it interesting anyhow:
<http://polyplex.org/cjh/software/adl>.

I'm still playing with the semantics of relationships, to encapsulate
the features of ORM. I haven't found a good way to indicate mandation
yet either - earlier work didn't need it but ORM does. This version
also doesn't talk about Method variables, it's purely for static data
modelling.

I look forward to your comments.

Clifford Heath.