Notes in KDE in the future

[Laura Dragan]

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.

Great idea, thanks for sharing. I've been following the discussion on
plasma-devel and was thinking that a meeting on irc might help to get to
a decision faster ..

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

This is a nice-to-have thing I would like to add to semnotes but later
on, so a nice API would really help :)

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

Currently I store the notes in the Nepomuk store together with all the
information about them. What I had in mind for Akonadi integration was a
sort of note resource that would synchronize the notes from nepomuk with
akonadi. I did not go further into it, as to decide if i should create a
new collection for these notes or they should be added to an existing
collection of notes, or how to store the relations i have for notes to
other nepomuk things like people, projects, etc. Storing these relations
between objects is what nepomuk is for, and i'm not convinced that it
makes sense to duplicate them in akonadi. It would be nice however to
have a nepomuk feeder that moves the notes from akonadi to nepomuk, so
that notes written in kjots / knotes / basket can be shown in semnotes.

You seem to have the storage in akonadi figured out - or almost .. so we
should think of a consistent way of storing them in nepomuk, and then
make the akonadi resource/feeder follow the formats we agree on. This
way, no matter where the notes are - files, akonadi, nepomuk - they
should be accessible and synchronized.

I plan to discuss the way i store the notes in semnotes at the nepomuk
meeting next weekend and hopefully get to a stable version, regarding
which classes/properties are best to use. So far I had not taken into
account other mime types than text, so this will be on the todo list as
well.


Laura

>
> All the best,
>
> Steve.
>
>
>
> _______________________________________________
> KDE PIM mailing list kde-pim@...
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
>

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Stephen Kelly-3]

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 kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Dr. Robert Marmorstein-2]

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@...
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
>

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Stephen Kelly-3]

Laura Dragan wrote:

> 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.
>
> Great idea, thanks for sharing. I've been following the discussion on
> plasma-devel and was thinking that a meeting on irc might help to get to
> a decision faster ..

I'm in the nepomuk-kde channel already if you want to ping me there at some
point.

>
>>
>> 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.
>
> This is a nice-to-have thing I would like to add to semnotes but later
> on, so a nice API would really help :)

Yes, that's a bit long term stuff, that I'm not aiming for this week or
anything, but I just want to use stuff that will make it possible in the
future without too much fuss.

>>
>> 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.
>
> Currently I store the notes in the Nepomuk store together with all the
> information about them. What I had in mind for Akonadi integration was a
> sort of note resource that would synchronize the notes from nepomuk with
> akonadi.

My initial reaction to this is that it shouldn't be necessary to attempt to
synchronize notes stores in nepomuk and akonadi. Having such a resource
would mean that semnotes would be using akonadi anyway, and then it would
make more sense to access the shared data instead of copying/synching, no? I
say that without knowing enough about how the stuff is stored in nepomuk, so
I may be missing a few important points.

> I did not go further into it, as to decide if i should create a
> new collection for these notes or they should be added to an existing
> collection of notes, or how to store the relations i have for notes to
> other nepomuk things like people, projects, etc. Storing these relations
> between objects is what nepomuk is for, and i'm not convinced that it
> makes sense to duplicate them in akonadi.

Right. My understanding was that these relations would be stored in nepomuk,
and the notes themselves in akonadi. That way it would be possible to create
relations in kjots too.

> It would be nice however to
> have a nepomuk feeder that moves the notes from akonadi to nepomuk, so
> that notes written in kjots / knotes / basket can be shown in semnotes.

Accessing the notes from akonadi directly would bring that for free, but
might impose other things that you may not want, such as heirarchical
structure of note collections, having to either choose a collection of notes
to deal with at a time, or otherwise deal with all the data in the tree and
having to handle notifications of new notes being added etc.

If your idea was that all notes from akonadi would be synched into nepomuk,
those are issues you would need to deal with anyway though.

>
> You seem to have the storage in akonadi figured out - or almost .. so we
> should think of a consistent way of storing them in nepomuk, and then
> make the akonadi resource/feeder follow the formats we agree on. This
> way, no matter where the notes are - files, akonadi, nepomuk - they
> should be accessible and synchronized.
>
> I plan to discuss the way i store the notes in semnotes at the nepomuk
> meeting next weekend and hopefully get to a stable version, regarding
> which classes/properties are best to use. So far I had not taken into
> account other mime types than text, so this will be on the todo list as
> well.

Cool, well it would be cool for us to talk on irc before that if possible
too to flesh out more ideas.

All the best,

Steve.

>
>
> Laura
>
>
>>
>> All the best,
>>
>> Steve.


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Stephen Kelly-3]

Dr. Robert Marmorstein wrote:

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

Yes, I see there's a lot of cool stuff in there. Things like ratings,
progress, priority, work/personal annotations, custom states and tags. Those
things could likely be stored in nepomuk though, not serialized to the note
itself and stored in akonadi.

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

Yes, such a port is definitely not trivial. I wouldn't want to try to guess
a timeline for any of this stuff.

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

I agree completely. That is also part of the convenience api that I had in
mind. KMime allows all manner of headers and structures that are relevant to
emails, but not to notes. For notes we probably need only the title, the
content, and maybe some details about the appearance, the date
created/modified, what application created it, and what type it is etc.

Potentially, that could mean notes look like this:

Subject: The title of my note
From: Kjots4.4@...
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is the content of my note.

== or ==

Subject: The title of my rich text note
From: Kjots4.4@...
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: text/html;

<html> ...
This is the <b>rich</b> <i>text</i> content of my note.
</html>

== or ==

Subject: The title of my rich text with embedded media note
From: Kjots4.4@...
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: multipart/related; boundary=content-boundary; type="text/html"
start="main-content"

--content-boundary
Content-Type: text/html
Content-ID: main-content

A <b>rich text</b> note with an embedded image: <img src="cid:image1" />,
and embedded sound: <audio id="audio" src="audio1" class="shadow"
controls></audio>

<br />
This note should also work as expected in konqueror.

--content-boundary
Content-Type: image/png
Content-ID: image1

T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=

--content-boundary
Content-Type: application/ogg
Content-Id: audio1

a3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIH=

--content-boundary


I don't know if that would satisfy the needs of basket? We'd probably need
to explicitly agree to what features should all of the applications support,
and whether an application can write other information to the headers which
the others can ignore, but must write out again when saving the note. That's
the kind of thing that is already possible with KMime I believe.


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

Yes, that would be nice too. We need some lowest common denominator feature
wise though. I'm not sure what format kpilot notes are expected to be in.

All the best,

Steve.

>
> 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@...
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>>
> _______________________________________________
> KDE PIM mailing list kde-pim@...
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

On Monday 02 November 2009 23:28:33 Stephen Kelly wrote:
> 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.
I'll just throw in a couple of comments about how notes are handled in the
exchange protocol (i.e. will need to be converted to in the openchange
resource). A note is just like an email or appointment - conceptually its a
row in a table on the server, where the columns are different properties (of
distinct types, and possibly multi-valued). The difference is in what
properties are allowed / required for each type of groupware object.

Notes in exchange (and hence outlook) are basically sticky note equivalents.
They have (in addition to the standard things every groupware object has):
1. a suggested background colour (blue, green, pink, yellow or white),
although in some versions of outlook the note category takes precedence over
this property.
2. A size (height / width, in pixels) and a position (x / y, in pixels) for
display.
I haven't yet investigated what outlook will do if they aren't present.

The note is supposed to have a subject (presumably a short summary of the
note). Outlook notes are plain text, but servers can often convert HTML or RTF
representations - probably need to test this.

No attachments (the spec says MUST NOT, so presumably that will cause problems
with some form of outlook or exchange server).
 
[If you're interested in the spec, a google search for MS-OXONOTE will
probably produce a link to MSDN, where you can view it in HTML or download the
PDF].

I'm reasonably comfortable that I can extend the server object set to support
arbitrary objects, although obviously outlook won't show the interesting  
bits.

> 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.
So the concept here is that a backend can provide whatever MIME format it can
handle (which might be just text/plain) and kjots will display it.

> 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.
Exchange / openchange can also do notes in arbitrary folder structures.
 
> 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.
Do you have an example of what the convenience API would look like?
 
> 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.
Stupid static strings is probably a fair assessment, but some of us don't have
nepomuk everywhere. So support for using simple static strings (even if they
get converted in awesome nepomuk strings later) is probably important.

I cut a bit of nepomuk stuff here that I don't understand fully, but I do have
a question about what the user sees. Lets say I have two separate desktops
(e.g. work and home), and I can (somehow) access my work groupware server from
both desktops (and perhaps some extra stuff like my private IMAP account, and
the gmail account that gets the not-safe-for-work stuff). However I don't have
a common filestore. If I create some tags on a note at work, what do I get at
home?

Brad
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Stephen Kelly-3]

Brad Hards wrote:

> On Monday 02 November 2009 23:28:33 Stephen Kelly wrote:
>> 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.
> I'll just throw in a couple of comments about how notes are handled in the
> exchange protocol (i.e. will need to be converted to in the openchange
> resource).

Cool, thanks for the input.

> A note is just like an email or appointment - conceptually its
> a row in a table on the server, where the columns are different properties
> (of distinct types, and possibly multi-valued). The difference is in what
> properties are allowed / required for each type of groupware object.
>
> Notes in exchange (and hence outlook) are basically sticky note
> equivalents. They have (in addition to the standard things every groupware
> object has):
> 1. a suggested background colour (blue, green, pink, yellow
> or white), although in some versions of outlook the note category takes
> precedence over this property.
> 2. A size (height / width, in pixels) and a position (x / y, in pixels)
> for display.
> I haven't yet investigated what outlook will do if they aren't present.

Hmm, colour, size and position are also the things that we'll want to
support in akonadi notes. I was going to store them in the plasma
configuration only, but if exchange would want to store them too, it might
make sense to put them in custom headers in the mime messages.

>
> The note is supposed to have a subject (presumably a short summary of the
> note). Outlook notes are plain text, but servers can often convert HTML or
> RTF representations - probably need to test this.
>
> No attachments (the spec says MUST NOT, so presumably that will cause
> problems with some form of outlook or exchange server).

Interesting. Is it impossible to say, drag and drop an image into a note
which is stored in exchange?

I'm not certain if supporting images/embedded media is definitely the right
thing for desktop sticky notes, but I think it is something that would make
sense in kjots. On the desktop small makes sense, but having a big image in
the note might make a note necessarily bigger. That could mean having some
separation between rich text only and embedded media notes with convert
to/move to/copy to actions, which is not so appealing.
</braindump>

>  
> [If you're interested in the spec, a google search for MS-OXONOTE will
> probably produce a link to MSDN, where you can view it in HTML or download
> the PDF].
>
> I'm reasonably comfortable that I can extend the server object set to
> support arbitrary objects, although obviously outlook won't show the
> interesting bits.
>
>> 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.
> So the concept here is that a backend can provide whatever MIME format it
> can handle (which might be just text/plain) and kjots will display it.

Yes. Well, almost. Whatever mimetype it wants would be too broad. I would
say restrict it to just text/plain, text/html and maybe multipart/related,
and try to get support for the three in any note taking application.

>
>> 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.
> Exchange / openchange can also do notes in arbitrary folder structures.

Cool, good to know.

>  
>> 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.
> Do you have an example of what the convenience API would look like?

Nope sorry. Haven't thought that far ahead yet. It might be just an
extension of QTextDocument which wraps a KMime::Message. QTextDocument has a
lot of features we're not taking advantage of yet.

>  
>> 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.
> Stupid static strings is probably a fair assessment, but some of us don't
> have nepomuk everywhere. So support for using simple static strings (even
> if they get converted in awesome nepomuk strings later) is probably
> important.

I see. Which applications would not have access to Nepomuk? I have no idea
if kde applications on windows can use Nepomuk, or do you mean non kde
applications?

>
> I cut a bit of nepomuk stuff here that I don't understand fully, but I do
> have a question about what the user sees. Lets say I have two separate
> desktops (e.g. work and home), and I can (somehow) access my work
> groupware server from both desktops (and perhaps some extra stuff like my
> private IMAP account, and the gmail account that gets the
> not-safe-for-work stuff). However I don't have a common filestore. If I
> create some tags on a note at work, what do I get at home?

My understanding of Nepomuk, which might be a bit cloudy, is that it handles
local annotations/relations. If I tag an email in kmail which happens to be
on an IMAP server, and then access that email from another application on a
different computer, the other application will not know anything about the
tag.

However, we could also conceivably define some custom headers in the mime
messages like

X-Note-Tags: giraffe,zoology

or something similar for Nepomuk annotations to indicate such things in a
transferable way. Then if you tag a note in a commonly accessible location
with giraffe on your work computer and other applications can process the
tag, it could be made to have the same tag when accessed anywhere.

So it's possible, but we'll have to see if it makes real sense or if people
want it like that. I do prefer the idea of tasks instead of tags, and
supporting both would probably be overkill, especially as applications would
need to have user interfaces for both.


All the best,

Steve.

>
> Brad
> _______________________________________________
> KDE PIM mailing list kde-pim@...
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/



_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Christian Mollekopf]

On Tuesday 03 November 2009 12:09:26 Stephen Kelly wrote:

> Brad Hards wrote:
> > On Monday 02 November 2009 23:28:33 Stephen Kelly wrote:
> >> 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.
> >
> > I'll just throw in a couple of comments about how notes are handled in
> > the exchange protocol (i.e. will need to be converted to in the
> > openchange resource).
>
> Cool, thanks for the input.
>
> > A note is just like an email or appointment - conceptually its
> > a row in a table on the server, where the columns are different
> > properties (of distinct types, and possibly multi-valued). The difference
> > is in what properties are allowed / required for each type of groupware
> > object.
> >
> > Notes in exchange (and hence outlook) are basically sticky note
> > equivalents. They have (in addition to the standard things every
> > groupware object has):
> > 1. a suggested background colour (blue, green, pink, yellow
> > or white), although in some versions of outlook the note category takes
> > precedence over this property.
> > 2. A size (height / width, in pixels) and a position (x / y, in pixels)
> > for display.
> > I haven't yet investigated what outlook will do if they aren't present.
>
> Hmm, colour, size and position are also the things that we'll want to
> support in akonadi notes. I was going to store them in the plasma
> configuration only, but if exchange would want to store them too, it might
> make sense to put them in custom headers in the mime messages.
>
> > The note is supposed to have a subject (presumably a short summary of the
> > note). Outlook notes are plain text, but servers can often convert HTML
> > or RTF representations - probably need to test this.
> >
> > No attachments (the spec says MUST NOT, so presumably that will cause
> > problems with some form of outlook or exchange server).
>
> Interesting. Is it impossible to say, drag and drop an image into a note
> which is stored in exchange?
>
> I'm not certain if supporting images/embedded media is definitely the right
> thing for desktop sticky notes, but I think it is something that would make
> sense in kjots. On the desktop small makes sense, but having a big image in
> the note might make a note necessarily bigger. That could mean having some
> separation between rich text only and embedded media notes with convert
> to/move to/copy to actions, which is not so appealing.
> </braindump>

Wouldn't it be better if you could just link the file (photo or whatever) to
the note (and the gui maybe displays it), instead of embedding it completely?
This way the file would be accessible also standalone, which would probably
pervent some data duplication.
It would also simplify the note format, since it is then really only text.
I don't know atm. how to make a "static" link to a file in the database, but i
guess it should be achievable somehow.

Just an idea...

>
> > [If you're interested in the spec, a google search for MS-OXONOTE will
> > probably produce a link to MSDN, where you can view it in HTML or
> > download the PDF].
> >
> > I'm reasonably comfortable that I can extend the server object set to
> > support arbitrary objects, although obviously outlook won't show the
> > interesting bits.
> >
> >> 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.
> >
> > So the concept here is that a backend can provide whatever MIME format it
> > can handle (which might be just text/plain) and kjots will display it.
>
> Yes. Well, almost. Whatever mimetype it wants would be too broad. I would
> say restrict it to just text/plain, text/html and maybe multipart/related,
> and try to get support for the three in any note taking application.
>
> >> 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.
> >
> > Exchange / openchange can also do notes in arbitrary folder structures.
>
> Cool, good to know.
>
> >> 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.
> >
> > Do you have an example of what the convenience API would look like?
>
> Nope sorry. Haven't thought that far ahead yet. It might be just an
> extension of QTextDocument which wraps a KMime::Message. QTextDocument has
>  a lot of features we're not taking advantage of yet.
>
> >> 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.
> >
> > Stupid static strings is probably a fair assessment, but some of us don't
> > have nepomuk everywhere. So support for using simple static strings (even
> > if they get converted in awesome nepomuk strings later) is probably
> > important.
>
> I see. Which applications would not have access to Nepomuk? I have no idea
> if kde applications on windows can use Nepomuk, or do you mean non kde
> applications?
>
> > I cut a bit of nepomuk stuff here that I don't understand fully, but I do
> > have a question about what the user sees. Lets say I have two separate
> > desktops (e.g. work and home), and I can (somehow) access my work
> > groupware server from both desktops (and perhaps some extra stuff like my
> > private IMAP account, and the gmail account that gets the
> > not-safe-for-work stuff). However I don't have a common filestore. If I
> > create some tags on a note at work, what do I get at home?
>
> My understanding of Nepomuk, which might be a bit cloudy, is that it
>  handles local annotations/relations. If I tag an email in kmail which
>  happens to be on an IMAP server, and then access that email from another
>  application on a different computer, the other application will not know
>  anything about the tag.
>
> However, we could also conceivably define some custom headers in the mime
> messages like
>
> X-Note-Tags: giraffe,zoology
>
> or something similar for Nepomuk annotations to indicate such things in a
> transferable way. Then if you tag a note in a commonly accessible location
> with giraffe on your work computer and other applications can process the
> tag, it could be made to have the same tag when accessed anywhere.
>
> So it's possible, but we'll have to see if it makes real sense or if people
> want it like that. I do prefer the idea of tasks instead of tags, and
> supporting both would probably be overkill, especially as applications
>  would need to have user interfaces for both.
>
>
> All the best,
>
> Steve.
>
> > Brad
> > _______________________________________________
> > KDE PIM mailing list kde-pim@...
> > https://mail.kde.org/mailman/listinfo/kde-pim
> > KDE PIM home page at http://pim.kde.org/
>
> _______________________________________________
> KDE PIM mailing list kde-pim@...
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
>

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Ingo Klöcker]

On Tuesday 03 November 2009, Stephen Kelly wrote:

> Brad Hards wrote:
> > On Monday 02 November 2009 23:28:33 Stephen Kelly wrote:
> > I cut a bit of nepomuk stuff here that I don't understand fully,
> > but I do have a question about what the user sees. Lets say I have
> > two separate desktops (e.g. work and home), and I can (somehow)
> > access my work groupware server from both desktops (and perhaps
> > some extra stuff like my private IMAP account, and the gmail
> > account that gets the
> > not-safe-for-work stuff). However I don't have a common filestore.
> > If I create some tags on a note at work, what do I get at home?
>
> My understanding of Nepomuk, which might be a bit cloudy, is that it
> handles local annotations/relations. If I tag an email in kmail which
> happens to be on an IMAP server, and then access that email from
> another application on a different computer, the other application
> will not know anything about the tag.
>
> However, we could also conceivably define some custom headers in the
> mime messages like
>
> X-Note-Tags: giraffe,zoology
>
> or something similar for Nepomuk annotations to indicate such things
> in a transferable way. Then if you tag a note in a commonly
> accessible location with giraffe on your work computer and other
> applications can process the tag, it could be made to have the same
> tag when accessed anywhere.
>
> So it's possible, but we'll have to see if it makes real sense or if
> people want it like that. I do prefer the idea of tasks instead of
> tags, and supporting both would probably be overkill, especially as
> applications would need to have user interfaces for both.

Just a quick remark that using headers for storing information is a bad
idea (at least when it comes to IMAP). By design IMAP does not allow
changing a message. In particular, adding or changing a header isn't
possible. The only way to do this is to delete the old version of the
message and add the new version of the message. Obviously, this is
overkill if all you want to do is add/change a single header.

Maybe there is an IMAP extension which allows this. I do know that there
is such an extension for adding flags (e.g. read, replied, important,
etc.) to a message. This extension is already used by KMail for making
KMail's message flags available from everywhere.


Regards,
Ingo


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

On Tuesday 03 November 2009 22:09:26 Stephen Kelly wrote:
> Brad Hards wrote:
> > No attachments (the spec says MUST NOT, so presumably that will cause
> > problems with some form of outlook or exchange server).
>
> Interesting. Is it impossible to say, drag and drop an image into a note
> which is stored in exchange?
Doesn't seem to be possible. I can't even change the font.

> I see. Which applications would not have access to Nepomuk? I have no idea
> if kde applications on windows can use Nepomuk, or do you mean non kde
> applications?
OK, I mean Outlook :-) The idea here is that if you're using outlook at work,
and you add a tag or category (aka stupid static string), then that would be
available in kde tools.
 
> My understanding of Nepomuk, which might be a bit cloudy, is that it
>  handles local annotations/relations. If I tag an email in kmail which
>  happens to be on an IMAP server, and then access that email from another
>  application on a different computer, the other application will not know
>  anything about the tag.
That would be unfortunate.
 
> However, we could also conceivably define some custom headers in the mime
> messages like
>
> X-Note-Tags: giraffe,zoology
I can do that, as long as we decide on what the convention is.

Brad
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/