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

[Gunnar Wrobel]

Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> On 11.10.2011 12:08, Gunnar Wrobel wrote:
>> Quoting "Jeroen van Meeuwen (Kolab Systems)"
>> <vanmeeuwen at kolabsys.com>:
>>> Gunnar Wrobel wrote:
>>>> You state again that all annotations are dependent on each other
>>>> and
>>>> can potentially conflict with each other.
>>>
>>> No, I don't state that. I state that in order to be able to safely
>>> configure
>>> feature $a on a folder, a client must be able to guarantee no
>>> feature $b
>>> through $z has already been configured on a folder, any of which
>>> *may* be
>>> mutually exclusive with feature $a.
>>
>> Why would the client need to guarantee that? Shouldn't the Kolab
>> format spec guarantee that?
>>
>
> If the format spec is to guarantee such a client's capabilities still
> have to be made up to spec in order to conform to the format, inherently
> causing the client to need to be able to guarantee; no matter where the
> restriction is specified, the client still has to be able to guarantee,
> on its own merits or to comply with the specification.

Correct.

>
>>> If feature $b through $z were stored in annotations the client has
>>> no
>>> knowledge of, it is then also unable to provide such detection.
>>>
>>>> I disagreed before and still do.
>>>>
>>>
>>> Then again, there's no strong objections against using one
>>> annotation;
>>
>> True, my objection is not a very strong one. But I am leaning towards
>> separate annotations and had the impression Bernhard did as well.
>>
>
> I have strong -and in my opinion very valid, and blocking- objections

I read through the complete discussion and wasn't aware that the  
people discussing this issue agreed there was a particular blocker  
that would make the "one large annotation" an inevitable choice. That  
is the reason why I offered my opinion.

> against using multiple or separate annotations, so I'm confused as to
> why we are still discussing this.

If you say the discussion has already been closed and I  
missed/overlooked some central points you are of course free to ignore  
my comments and move on.

> No other alternatives have been
> provided, no blocking objections exist against using one annotation.

I was still considering using several annotations a feasible choice.  
But I guess that has been obvious from my mails today.

>
> I certainly hope "leaning towards" nor the perception that the KEP
> process establishes a democracy does not trump technical feasibility.
>
>>> it
>>> seems we're arguing just for the sake of arguing, and going
>>> absolutely nowhere
>>> while doing so.
>>>
>>> I have yet to recognize any objections against using one annotation.
>>
>> I mentioned before that I do not see any reason why clients such as
>> the Z-Push active sync client should fetch any Horde specific
>> configuration.
>>
>
> This isn't a serious objection.

Not as long as the "one large annotation" remains rather small. Do not  
get mislead by that one Z-Push/Horde exmple: It is not only Z-Push  
fetching annotation it does not need. It is also the free/busy system,  
the resource management and all the other Kolab clients.

My impression was that the "one large" annotation can however get  
rather large. In addition it needs to be read and written very often.  
I don't see why that should not result in problems. Not *huge*  
problems - but I consider it more problematic than using several  
distinct annotations.

If I look at the "folder-type": It only gets written once by the first  
client to create a folder and read once by every client. Why lump that  
into a big blob that has very different characterics?

> Horde itself has stored configuration
> in annotations, something very likely to change with the adoption of a
> more widely usable configuration storage definition. Also note that the
> use of one annotation for configuration that is shared amongst various
> clients and application is *NOT ACTUALLY* mutually exclusive with adding
> annotations to the arbitrary whim of a single client choosing to use its
> own methodology to store arbitrary stuff.

Sure.

> It does however form the basis
> of consolidation of arbitrary stuff, and a richer Kolab experience as a
> result.

Hm, not convinced.

Cheers,

Gunnar

>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +44 144 340 9500
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de