Question: Individual annotations vs One large annotation (conceptual riddle for the interested)

Georg C. F. Greve greve at kolabsys.com
Thu Sep 15 17:20:26 CEST 2011


On Thursday 15 September 2011 15.52:33 Jeroen van Meeuwen wrote:
> First of all, the same argument would apply to both clients operating
> either the 'search' or the 'color' separate annotation -if in the same
> namespace.

Yes, but a "last write wins" scenario for color is just fine, because that is 
what happens anyhow.


> Fifth, 'search' is more likely to be a shared annotation (value)
> whereas 'color' is most likely set once in the shared annotation (value)
> for the default, but edited in the private annotation (value).

This is actually a reason for individual annotations, in my view.

Because the shared/private namespace behaviour will often be very annotation 
specific, a 'folder-config' annotation, which would also have to live in both 
namespaces, would have different precedences for different key/value pairs.


> Wrong, as there may be annotations a client is unaware of, that may be
> conflicting with annotations the client is planning on setting.

Annotations are always defined per use case. Orthogonally, if you will.

Thus there can be no conflict between different annotations as long as we 
properly define them, and if there *was* a conflict, it would affect the folder-
config in the same way as it would the annotations.


> > Only with the large annotations you always must read everything.
> 
> Wrong, the client *retrieves* the full annotation value but only needs
> to read;

That is pure semantics. The point was that the annotation must be transmitted 
in full, and JSON parsers will typically parse the full annotation and then 
translate it into an array which it serves through the API.

So the bandwidth and computational weight is always incurred, even if a client 
just wants to know a single binary value within that complex 10k annotation.


> Wrong, this is not equally true for the "large" annotation, as with the
> large annotation (the client now aware of where to find folder specific
> configuration) the folder-type is freed up and *can* be used for the
> original object type, with pre-population allowing said client to still
> use the saved search - note, *can* be used for the original object type,
> not *must* be used, perhaps it does have a different value, such as
> 'mixed' for example.

There seems to be a fundamental disconnect here.

folder-type cannot be busied or freed up by either route.

Even if we were to go with a large folder-config annotation, the folder-type 
annotation would likely remain the same, and an additional value 'search' 
would still provide the same use case as it did before.

The same is true if one were to completely lose the 'folder-type' annotation 
and also stuff it into the folder-config, which by the way would seem 
counterintuitive considering the special-use case.


> Changing (copies of) objects (only applicable if folder is
> pre-populated) in saved search folders by clients not compatible with
> KEP #15 is mixture of implementation detail and a saved search folder
> permission problem, resolved by restricting the user to not allow
> editing the contents of said folder at all *if* and *only if* such
> folder is to be pre-populated at all, being worked around in a fashion
> that makes any folder implementing any of these new features be ignored
> by the client -which it never does completely?

That does not parse.

The point of saved searches is that each client of a user can access these 
searches, and update them. In order to update them, it must be able to read 
and write the search folders, otherwise nothing will be prepopulated.

If it can delete/write objects to the folder, it can modify existing objects.


> and whatever else we can come up with has a purpose / use-case valuable
> enough to pursue. Adding annotations for each of these 1) on the server,
> 2) in every client and 3) in the documentation is more difficult of a
> process then if we were to outline a key-value pair in an existing
> annotation.

No, because there is zero difference in the weight of the process to define a 
key/value pair or a new annotation. Both require a KEP, both will have the 
same conceptual issues to resolve, plus a potential additional complication 
for the shared/private conflict resolution for the large annotation.

Creating the folder-config annotation also has the overhead that we need an 
additional KEP to define how the process around this is supposed to work.

So procedurally speaking, the large annotation will be more work.


> Again, firstly, with many annotations retrieving any annotations is
> subject to the client's understanding of which annotations are available
> and the server's understanding of what are valid annotations.

Yes. Same for folder-config to which unknown keys just add dead weight that 
must be preserved on the assumption that there is some reason for them to 
exist.


> Secondly, with many annotations, in order to be able to determine
> whether or not there is a potential conflict, and in order to be able to
> determine which takes precedence when content is retrieved for display,
> all annotations will need to be retrieved.

No. As each annotation addresses one use case, an application in that use case 
will only need to retrieve that one annotation, and can ignore the rest. 


> And one against *potentially* preserving the original folder-type
> value;

The folder-type value *may* be replaced against specialuse attributes if we 
can find a way to do that properly, there is a case for that. 

But other than that I haven't seen a realistic case for not preserving it.

Note that the question of potentially adding a new folder-type *value* has no 
bearing whatsoever on the conceptual issue of "one annotation per use case" vs 
"one large annotation for everything." They are separate issues.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110915/33e96d8b/attachment.sig>


More information about the format mailing list