[Kde-pim] Notes in KDE in the future

[Dr. Robert Marmorstein]

I forwarded this message to basket-devel.  It sounds like a good way to 
possibly standardize the "note" format so that different interfaces can share 
them.  Of course, in BasKet, notes are pretty fancy, so it's especially 
difficult to serialize them.  

In fact, this is the biggest barrier to Akonadi integration right now: 
factoring out the data about notes that is spread out over dozens and dozens 
of C++ classes.  

While using KMime is a good foundation for sharing notes between applications, 
there are going to be a lot more implementation details that we need to work 
out.  It would be good if we could set up a more formal structure for joint 
standardization of a common "notes" format.  

>From my perspective, it would be nice if we could also keep things compatible 
with kpilot's notes conduit....

Robert

On Monday 02 November 2009 7:28:33 am Stephen Kelly wrote:
> Hi,
> 
> Following from the thread we had last week about notes I'd like to thrash
> out a few ideas and see if we can get some agreement/consensus about how to
> serialize the data, how to share notes between different applications, how
> nepomuk fits in, and what the user experience should be. Unfortunately I
> won't be going to the Nepomuk meeting, but as it's coming up soon I thought
> I'd get the ideas out as are currently in my head at least.
> 
> KJots currently stores top-level books in an xml format. The entire
> heirarchy below a top level book including its child books is stored in one
> file. The data is pretty much always converted to html, not giving the user
> a chance to make a note plain text only. On the other side, it is not
> currently possible to store images and other media like sounds for example
> in kjots notes.
> 
> As a starting point for allowing such things, I've started to convert kjots
> in the akonadi ports branch to use mime messages as notes. This has several
> advantages especially relating to akonadi, because we already have the
>  kmime library for handling mime messages, akonadi has a serializer for
>  mime messages, having different messages of different mimetypes is normal
>  in mime, eg text/plain, text/html, and multipart/related for text with
>  media.
> 
> There are also several good storage solutions for mime messages, like
> maildir for example which allows storage of a heirarchy of notes. We
>  already have a maildir resource in akonadi, so it was possible to subclass
>  that and use it for notes too. All I had to do in the subclass was make it
>  use a different mimetype, text/x-vnd.akonadi.note to differentiate from a
>  resource holding actual mails. Volker already made it possible to store
>  the notes on a kolab folder too.
> 
> For the above re-use of existing akonadi code I think it would be a good
> idea to use mime structures for notes. For applications, this means dealing
> with KMime::Message::Ptrs, which are boost::shared_ptrs instead of whatever
> notes class was used before. This is not very convenient, so it might be
> possible to make some more convenient API for handling notes which doesn't
> need all the complex stuff in kmime. The applications of course don't care
> if the notes are in maildirs or on kolab if they just retrieve them from
> akonadi.
> 
> For applications using akonadi, I think a challenging aspect is dealing
>  with notifications coming from akonadi in a sane way. Akonadi could notify
>  at any time that a new note has been inserted by another application into
>  a notes collection and must be shown in your application too. This has
>  been causing some discussion in the attempt to put notes from akonadi into
>  the plasma workspace, because there are several ways to do it, none of
>  which cover everything we want to do.
> 
> My current idea is to put notified new notes into a extender and have one
> master applet with each note as a plasma extender item.
> 
> Unfortunately the gmane view onto plasma-devel@ is broken, but you can see
> it here:
> 
> http://markmail.org/search/?q=how%20to%20get%20akonadi%20notes%20into%20pla
> sma#query:how%20to%20get%20akonadi%20notes%20into%20plasma+page:1+mid:uvsxf
> wpgqpor74iy+state:results
> 
> http://officespace.kdab.net/~stephen/notes_plasma.ogv
> 
> One of the nice things about that is that a particular plasma activity
>  could show a particular collection of notes, including only notes
>  annotated in a particular way by nepomuk. So you could have your
>  "organizing the football team" plasma activity show the notes associated
>  with the task or project "organizing the football team". Sebastian Trueg
>  has mentioned before that simple tags shouldn't be used here, because tags
>  are "stupid static strings", and something like tasks can have more
>  meaning in nepomuk.
> 
> There was an idea of allowing any search folder to be used in plasma for
> example, but I don't think that would make sense. For example if you were
> showing notes containing the work "giraffe" and you create new note in
> plasma, you expect it to show up on the workspace. We can't just put the
> word giraffe in there to make that happen, so I think we should try to
> restrict notes apps to associating notes with tasks or whatever ontology is
> deemed best.
> 
> Then if a new note is created while showing notes in the "Organizing the
> football team" notes collection, it automatically gets associated with that
> task. That would mean that each of the notes apps would need some user
> interfaces for associating notes with tasks. Another difficulty that arises
> is that notes created in that way would have to exist in some concrete
>  notes collection before they could be put into a virtual collection of
>  notes for a particular task. One option would be to put them into a
>  "Unsorted" notes collection in a local notes resource.
> 
> Another aspect of notes which I think needs to come into all of the
> applications is more semantic annotation of the content of the notes, which
> is what semnotes already does. That is orthogonal to the rest of the stuff
>  I wrote about, but it is something else for the application developer to
>  have to implement support for.
> 
> What do you think of all this? I realize that sharing data between the
> different notes solutions is a lot harder than each one rolling their own,
> and it could impose some restrictions on the applications, but it will
> hopefully make and could give nice user interaction and choice/swapping
> between applications.
> 
> All the best,
> 
> Steve.
> 
> 
> 
> _______________________________________________
> 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/