[dev] Re: Adding contact to nag task [Patch]

[Jeroen Huinink]

"Hans Lellelid" <hans at appliedsec.com> wrote:


> >It already was my intention to generalize what I had so more. I had some
> >ideas on that, but what you are talking about takes this a bit beyond
that.
> >I was thinking about introducing some sort of Unique Identifier concept
> >(what I now called keyFields in Turba) that allows applications to link
into
> >each other. We could create a horde_crosslink table that contains four
> >fields:
> >from_application, from_UID, to_application, to_UID.
> >This also allows associating Notes with Tasks and/or Calendar Events or
even
> >to link Tasks to each other (follow-up tasks).
> >This would result in something like the following set of APIs
> >
> >UIDFields: This should return the set of UID fields.
> >searchUID: This seach should at least return the UID.
> >showByUID: This should show a page with the associated element
> >descriptionByUID: This should retreive a description that can be used to
> >show in an external links list.
>
> Yeah -- this is very cool.  Sorry -- I wrote my previous post before I
> had seen your note (duh!).   One thing I was thinking -- it might make
> sense to have one additional field in this crosslink table: something
> like `relationship_id`.  It is conceivable that the same object types
> would need to be related in different ways.  E.g. a person (Turba?) and
> document (Gollem?) could be related in several ways: document author,
> document poster, current document holder (checked out), etc.  The app
> that is concerned with the relationships might want a way of tagging
> these various ways that items can be related.  Of course the field could
> be ignored if you simply want to know "everyone associated with this
> document".

Good idea. Although I'ld rather call it "relationship_type". Which
application
defines the possible values for the relationship types? Would that be the
source application only or could this also be the target application?
The links that are defined here are directional. There is a "from" and there
is a "to". Of course these links can be reversed. E.g. working from Gollem
I have a set of documents and each has an author associated with them. If I
go into Turba I would like to have the ability to find all documents that
have
a certain author.

Using the Turba registry I can express the fact that you can link into it
with
function like those I already mentioned. This is how we add "authors" to
Gollem documents. How can I express through the Gollem registry that it
is usefull for Turba to have an "Authored documents" button somewhere?
I can probably come up with something or look into the RDF, xlink or
similar specs and see how they handle this, but it would be usefull if
somebody with knowledge or ideas in this area would put in his suggestions.

> When I originally imagined the crossref table, I was thinking that it
> would just be 3 fields:  from_uid, to_uid, and rel_id.  I was imaging
> that the app name would be part of the UID fields -- e.g.
> 'turba:myusername at mydomain' or 'nag:12'.  I think that storing the apps
> probably makes a lot of sense, however.  One question -- what about
> different apps that may provide the same functionality?  -- e.g. if  I
> create a "people" app that provides 'contacts' (just like Turba) would I
> want to be able to access the relationships in the crossref table?  ...

I was thinking about storing "contacts" in the application field instead of
"turba". I haven't really thought about having two applications providing
"contacts" is that even possible in Horde. If you use a "contacts" API,
how do you determine which one to use in such a case? I think my
approach solves your problem. If it could even exist within the Horde
framework though.

> Again, just thinking out loud :-)

You're welcome to it. Same here.

I'll rewrite what I had for the nag-turba integration into a general link
mechanism with the five fields discussed above. I'll not use the
"relationship_type" field yet and we have to come up with a solution to
express the possible relationship and backwards linking in the registry.

Regards,
Jeroen