4.5 - Activities

[Ivan Čukić]

> sorry, i wasn't clear enough. i meant where in kdelibs :)

:) I have no idea :)

> i'd recommend workspace/libs/kworkspace/. runtime isn't for libs :)

Ok :)

> runtime isn't for libs; and i think it does make sense next to Consumer.
> perhaps they could both go into kdelibs/nepomuk? would have to ask the
> nepomukians of course.

I'm not really sure about that - things in nepomuk tend to be rather generic 
compared to this. This is something that uses nepomuk, and is not really part 
of it (we could live w/o nepomuk, and nepomuk will certainly exist w/o this :) 
)

From my POV, it should be provided alongside KApplication...

> ah, so this is a way to expose the window<->document relationships; the API
> makes it sound like it's document related rather than window related.
> registerWindow perhaps?

It is intentional for two reasons:
 - we want it to look document oriented
 - more than one document can be in the same window - it would be strange to 
have to call registerWindow twice because we have two documents/resources in 
it.

> where does Info store this information? and shouldn't the persistence be an
> implementation detail that users of the classes shouldn't need to worry
> about? right now it's confusing as to which class to use given the
> duplication in API.

The idea is that Consumer class is an entry-level API - minimum for it to be 
able to *react* to activity events.

Info class, on the other hand, should be for the applications that really want 
to use activities (to be active participants instead of being only bystanders)

> ActivityConsumer doesn't represent a single Acitivity, it represents the
> collection of them, so the symmetry isn't exactly perfect there.

No, the analogy is not full, it is just the closest one I found.

> ActivityInfo does give information about an activity, though, and that
> seems quite sensible if the division of labor between the classes is
> Consumer for the collection and Info for individual activities.

The reason for this division was that Consumer is fully functional without 
nepomuk and Info is fully non-functional without it. I know it is not a good 
OO design, but it seems more sensible to me than to have a half-functional 
class depending on nepomuk even if it is a cleaner OO design.

Anyway, it can be easily changed if needed.

> the mechanism for tracking location will be in plasma-*, yes. but how will
> that work, exactly? will they have to go through Nepomuk directly? to me,
> the "where" is as central to the topic of Activities (as the word is used

Locations will be resources like documents and everything else.

> even go so far as to suggest that there should be a LocationResource in
> the ResourceType enumeration.

Ok, good enough for me, but it can only be added when the Location gets its 
ontology (to be more precise, to get the type uri). Adding an item to an enum 
is not BIC, right?

> another API quesiton: QList < KUrl > associatedResources() const;
> could that take an optional ResourceType arg so that one can pull out just
+1

Cheerio,
Ivan

-- 
Those people who think they know everything are a great annoyance to those of 
us who do.
   -- Isaac Asimov