[Prev][Next][Index][Thread]
Re: Annotations, sets, & servers
> From roscheis@Xingu.Stanford.EDU Mon Oct 16 18:34 PDT 1995
>
> >From gramlich@Sun.Com [...]
> >
> >But what about the other way around? Can one annotation set be
> >broken across multiple servers? For really large annotation sets
> >(billions of entries), it might be desirable to split up the
> >load across many machines; indeed, I can envision some annotation
> >sets that are geographically dispersed around the world. (It turns
> >out that the architecture of my prototype annotation proxy supported
> >cross machine annotation sets.)
> >
> >For example, I might have 26 machines allocated such that they
> >served up annotations based on the first letter organziation name.
> >Thus, the annotations for objects on http://www.W3.org/... would
> >go to machine W (for W3) and the annotations for http://www.Sun.com/
> >would go to machine S (for Sun).
>
> Fine. But I would claim that this is the wrong level to think about
> these kinds of issues. Every annotation server has a database backend
> which basically stores the annotations for each set. (How this is done
> is not part of our job here now.) You can easily realize your above
> example by simply picking a distributed database for this backend in a
> specific case (or, as mentioned before, use a shared file server
> realization). No problem. The question is whether to move all these
> issues up one conceptual level and consider the concept of a set to be
> distributed. And here I argued that the additional complexity in
> terms of access control etc. does not warrant this extra step,
> especially since it isn't a good idea anyway to mix up conceptually
> distinct issues.
>
> Another way to put this is that annotation hot spots will happen, but
> solutions to it are orthogonal to the protocol. There should be a
> general solution to this problem, and the same solutions which are
> used for document hot spots should then be applied towards annotation
> hot spots. (And, as you pointed out before, the basic constraint is
> that architecture should not make things worse than they are.)
As long as the annotation sets are relatively small and you can
build a single server that can meet all requests, I agree with
the premise of not exposing the structure of annotation sets.
This is good programming 101, `expose the interface, not the
underlying structure.'
My concern is truly large annotation sets (billions of entries).
It will be almost impossible to build a single server that serve
up such a large annotation set with millions of simultaneous users.
eWhen we attack that particular scalability problem, there may be
good reason to expose some of the underlying structure in order to
improve scalability.
Until we attack the humungous annotations set problem, it is
perfectly reasonable to say at the higher conceptual level.
-Wayne