It is better for annotations to have a "aimedTo" attribute.

[GoogleCodeExporter]

It is difficult to have an access control in annotations.
Then, it is better to have a "aimedTo" attribute in annotations, where you 
can include the addresses of participants to whom the annotation is aimed.
If "aimedTo" attribute is an empty string, then this annotation is aimed to 
all participants.

This is not access control so all participants can theoretically see the 
annotation, so there is no difficulty in implementing it.

There are at least two benefits.

1. Those who are not listed in the "aimedTo" attribute may not be bothered 
by unrelated annotations.
2. This can make it possible to make a faster client javascript program.

Let's take an example of hyper-link. Consider this hyper-link links to 
another wavelet.
If the wavelet is a private reply whose participants are aaa@xxxx and 
bbb@yyy, then aimedTo="aaa@xxxx,bbb@yyy".

The client javascript program may ignore the annotation if you are not 
included in the aimedTo attribute.
In this way, you can avoid messy unrelated annotation display.
And the client javascript can run faster, because it does not need to check 
whether you have a right to access to that wavelet.

Original issue reported on code.google.com by finitefi...@gmail.com on 23 Jul 2009 at 10:26

[GoogleCodeExporter]

Original comment by btkalman@gmail.com on 29 Aug 2009 at 2:08

[GoogleCodeExporter]

I like your point about filtering out annotations. There are two levels:
1. Receive them on the client, then ignore and don't render them
2. Request the server not to send them at all, thus also saving bandwidth and 
memory to transfer and store 
annotations that we just want to ignore

Unfortunately, we can't implement (2) at the moment, because the OT algorithm 
requires knowledge of ALL annotations, 
and so they must be sent and stored in the client's data structure. We might be 
able to partially solve this issue 
in the future, so that clients can specify annotations that don't interest them 
to avoid wasting resources on them.

If I understand correctly, your suggestion is aimed at case (1), to avoid 
wasting CPU and memory in rendering UI for 
the annotations. However, wouldn't you agree that this kind of thing is 
possible already? There are several ways of 
doing it
 * The client code could choose to interpret the information in the annotation key to know if the annotation should 
be ignored, (or the annotation value or linked documents/wavelets, but I think 
the key is most efficient)
 * Users could themselves choose to ignore certain types of annotations, as their own choice. For example, a user 
might not want spelling annotations cluttering up their wave, so they could 
turn those off. They are already turned 
off in the mobile client for efficiency reasons.
 * In your hyperlink example, the client could also detect where the link goes: does it go somewhere without access? 
or somewhere that doesn't exist? It could then provide a nice UI that is 
appropriate to the specific situation. 
There might be more cases than can be handled by just a participant list. 

There are a also few potential issues that I can think of with having a 
specific aimedTo attribute
 * It's another "feature" that adds more complexity to our already quite complex protocols and OT algorithms. Given 
that it is implementable with the existing feature set, it's best to avoid 
adding it in as a first class citizen.
 * There will still be work involved to parse & interpret the participant list, which is similar to the work in 
interpreting a value and then deciding to ignore it, and more work than just 
ignoring certain key prefixes 
altogether.
 * What about if we want to include another person on the annotations for a document? Do we have to go and update 
all the annotations and add them? It might be better to store this information 
separately in a single place
 * What about other types of filtering: for example, specifying a list of users to exclude, rather than include. 
Again, these needs would be on a case-by-case basis and you'd want to tailor a 
solution for your specific use case, 
which can be implemented with the existing primitives.

So I agree with your motivations, I am just of the opinion that the problem is 
solvable with the existing set of 
primitives.

Original comment by daniel.d...@gmail.com on 17 Nov 2009 at 1:10

[GoogleCodeExporter]

I see.

Original comment by finitefi...@gmail.com on 17 Nov 2009 at 3:08

[GoogleCodeExporter]

Original comment by oh...@google.com on 21 Nov 2009 at 4:01

• Changed state: WontFix