[Kde-pim] Proposal for a new pim application

Tue Dec 8 21:43:10 GMT 2009

On Tuesday 08 December 2009 19:35:54 Stephen Kelly wrote:
> Christian Mollekopf wrote:
> >> Did you see my recent screencast about notes on the desktop? I didn't
> >> demo it, but you can also create a new note on the desktop and it goes
> >> into an "unsorted" collection of notes which can be organized later.
> >
> > yes, i had a look at it and it looks really cool. But I don't think
> > plasmoids are the suitable interface for handling a lot of notes/todos.
> > As reminder though, or if one just uses notes from time to time,  it
> > looks perfect =)
> 
> Yes, I agree. It would work better by handling only a selection of notes.
> 
> >> > Functionality:
> >> > -a quick interface to create new notes, todos, ?.
> >>
> >> In progress?
> >
> > Not really, I'm having a look at semnotes at the moment, but in semnotes
> > it seems the notes are stored directly in nepomuk, while we probably
> > should store all notes in akonadi and pull in related data via nepomuk
> > (according to what you mentioned).
> 
> Hopefully. I'd like to know more about how notes can be stored in nepomuk
> too though as (I think) nepomuk does.
> 
> > Agreed, tagging is just the most simple and basic way to associate data.
> > Of course this doesn't use the full power of akonadi and nepomuk, and we
> > should definitely try to use such "advanced tags", which can be
> > understood by nepomuk. Nevertheless i think, manual tags are a good
> > starting point, since it already allows to do a lot, and should be the
> > most trivial to start with.
> 
> That is probably the most pragmatic way to go right now, yes.
> 
> > Ok, so this would mean the main interface to the data is akonadi, which
> > itself gets more data from outside (non pim data), via nepomuk.
> 
> I think that should work. From the way we've been making akonadi and
>  nepomuk work together to handle mails/contacts so far it seems to work
>  well.
> 
> >> I would like to know more about data retrieval with nepomuk, but that is
> >>  the kind of thing that akonadi is specifically for. I guess feeding
> >> data from akonadi into nepomuk would work if we had a resource to do it,
> >> but right now I'm not convinced it is the way to go. That could be just
> >> my ignorance shining through though. I agree that new notes/todos should
> >> be created through Akonadi apis.
> >
> > According to what you said above, it should go the other way round,
> > right?
> >
> > application <= akonadi <= nepomuk
> 
> Yes that's how I would envision it, but I think SemNotes works on data
> stored in Nepomuk, not just metadata. I'm not certain though, and I haven't
> had time to investigate more of that myself.

Yes, as far as i understand it, SemNotes stores the entire data in the Nepomuk 
database. Since the notes are usually rather small this is not a problem 
(laura checked once with the nepomuk people if the data should be stored in 
files better).

However, after thinking about it, i don't agree fully with you how the 
databases should work together (maybe because my lack of understanding...)

As I understand it akonadi is a PIM data storage/cache. It is therefore clear 
for me, that notes have to be stored in akonadi (where the notes finally are, 
on a central server or on the filesystem, is up to akonadi).

Nepomuk is responsible to figure out relations between data, and does not care 
at all where the data is stored (but it is also not a storage container 
itself).

Therefore the only proper way to handle notes with akonadi and nepomuk would 
be (as i understand it), that notes are always stored directly in akonadi, but 
the retrieval goes always via nepomuk (which gets the data from akonadi).

Since akonadi has nothing to do with data relations (but only with data 
retrieval), i don't understand how notes, stored in akonadi, could be related 
to data outside of akonadi, if we access the data via akonadi.
Therefore i don't think that a virtual collection with the nepomuk results in 
akonadi can be a solution, since it excludes the akonadi data from the 
relational stuff.

Of course notes could be also handled purely within akonadi, without using 
nepomuk at all, this would just remove all the advantages from nepmuk, and 
make the notes completely stupid about any relations.

To say it in another way, i see akonadi and nepomuk as two layers:
-akonadi as low level data storage
-nepomuk as next higher level, containing all meta/relational data of the 
lower level data

This is probably too much simplified, but did I understand something completely 
wrong?

Cheers,

Chris

> 
> > Thanks for all the info and input,
> 
> Sure. I'm available for more whenever.
> 
> All the best,
> 
> Steve.
> 
> > Chris
> >
> > _______________________________________________
> > KDE PIM mailing list kde-pim at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-pim
> > KDE PIM home page at http://pim.kde.org/
> 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
> 
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/