User talk:Harikrishna/Architecture/design decisions

Hide Nepomuk association from Dikku's APIs

The Context framework would provide the access to what the current context is (by name), a list of all currently known contexts (again, by names), etc, thus hiding any Nepomuk details from its APIs.

We plan to take this approach because there are some parts of the context which probably are not suitable to Nepomuk. an example of this is the current location of the system/user; we'd probably use geoclue for this, and will change orthogonally to the user's current activity (or project). e.g. just because i am on a train from France to Germany, it doesn't mean what i'm working on magically changes when i cross the border ;)

things can certainly be "geotagged" using Nepomuk, of course, but i want to give easy access to what the current location is separate from that since that is hardly the only use for it (the clock, for instance, may want to change timezones automatically) and things should not need to speak directly to geoclue for that information IMHO.

> if location is going to end up being broadcast by nepomuk, that implies > making nepomuk a "front end" to things like geoclue, does it not?

I don't think the location should be broadcasted by Nepomuk. I think that is a different source which should be kept separate. We could map the current location into Nepomuk though, to make things simpler for queries.

Keeping number of context types low

Aaron Seigo says:
i begin to grow concerned that we'll end up with N different active contexts and it will become rapidly unwieldly for the user and/or application developer. i really think that keeping it as simple as possible is critical to getting wide adoption and usage.

we can come up with something that models the Real World perfectly, and then probably nobody will actually use it because it will be too complex.

i'm looking for some simple abstractions that map to real world use scenarios here. those include things like:

• "I am currently working on my book, but will be working on my programming project in a few hours."

• "I'd like to get widgets relevant to the train station I'm lost in."

these are things that users find useful (some of them are already exposed in Plasma today and being used successfully!).

Times in contexts

> we should put start times on all > Contexts (the creation time is an implied start time) and make end times > optional, that way we can timeline all of them.

all resources have a creation time. But I think the start time of a task or project can differ from that. So I would still vote for start and end times assigned to a subclass of Context.

> yeah, the more i think about the time aspect of things, the more i think we > shouldn't make it optional.

Conceptionally a context does not have an end time so it does not make much sense IMHO.