Difference between revisions of "User talk:Harikrishna/Architecture/design decisions"

Jump to: navigation, search
Line 1: Line 1:
=== Hide Nepomuk association from its APIs ===
+
=== Hide Nepomuk association from Dikku's APIs ===
  
 
The Context framework would provide the access to what the current context
 
The Context framework would provide the access to what the current context
Line 26: Line 26:
  
 
=== Keeping number of context types low ===
 
=== Keeping number of context types low ===
 +
'''Aaron Seigo says:''' <br/>
 
i begin to grow concerned that we'll end up with N different active contexts
 
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
 
and it will become rapidly unwieldly for the user and/or application
Line 37: Line 38:
 
here. those include things like:
 
here. those include things like:
  
* "I am currently working on my book, but will be working on my programming
+
* "I am currently working on my book, but will be working on my programming project in a few hours."
project in a few hours."
+
  
 
* "I'd like to get widgets relevant to the train station I'm lost in."
 
* "I'd like to get widgets relevant to the train station I'm lost in."

Revision as of 17:33, 27 August 2008

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


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal