Interesting e-mail from skelly of Akonadi/Nepomuk fame that went out to the KDE-PIM mailing list today. We might want to think about also using KMime for representing notes in a way that can be exported to Akonadi.
--Robert
--- Begin Message ---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%20plasma#query:how%20to%20get%20akonadi%20notes%20into%20plasma+page:1+mid:uvsxfwpgqpor74iy+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 [email protected] https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/
--- End Message ---
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Basket-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/basket-devel
