John,

I pretty much second your concerns.

Do you know Edge Side Includes (ESI)? I was thinking about using them
with XSLT and Varnish to compose pages from remote XHTML fragments.

Regarding scalability -- I can only see those possible cases: either
Wikidata will not have any query language, or it's query language will
be SQL with never ending JOINs too complicated to be useful, or it's
gonna be another query language translated to SQL -- for example
SPARQL, which is doable but attempts have shown it doesn't scale. A
native RDF store is much more performant.

Martynas
graphity.org

On Thu, Jun 21, 2012 at 11:34 PM,  <jmccl...@hypergrove.com> wrote:
> Hello,
>
> For the current demo system, how many triple store retrievals are being
> performed per Statement per page? Is this more or less or the same as
> expected under the final design? Under the suggested pure-transclusion
> approach, I believe the answer is "zero" since all retrievals are performed
> asynchronously* with respect to client wiki transclusion requests.
>
> Are additional triple store retrievals (or updates) occurring? Such as ones
> to inform a client wikipedia about the currency of Statements previously
> retrieved from wikidata? In a pure-transclusion approach, such info is
> "easy" to get at: clients query the [[modification date::]] of each
> transclusion. Can you point me to a (transaction-level) design for keeping
> client wikis in sync with Statement-level wikidata content?
>
> I'm also concerned about stability & scalability. What happens to the
> performance of client wikis should the wikidata host be hobbled by DOS
> attacks, or inadvertent long-running queries, or command line maintenance
> scripts, or poorly designed wikibots or, as expected, by possilby tens of
> thousands of wikis accessing the central wikidata host? Under the
> pure-transclusion approach, my concerns are not nearly the same since all
> transcludable content is cached on squid servers....
>
> Thanks - john
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>

_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Reply via email to