Re: Bandwidth efficiency

On Wed, Jun 02, 2004 at 05:58:28 -0700, Howard Katz wrote:
> > The situation where the namespaces are declared after the results is not
> > much better as the client cant interpret them untill its parsed all the
> > namespace decls anyway.
> 
> Right. So what you're saying is that the tradeoff is basically between :
> 
> (1) taking processing time to compute the namespace of every uri in the
> result set before they depart the scene, or
> (2) leaving it to the client to do the inverse operation following arrival,

I dont think I follow. If the server just streams the results with fully
qualified URIs then the server and client doesnt have to do anything, but
it takes more bandwidth.
 
> I wouldn't have thought that (1) was all that expensive offhand -- I need to
> have some hands-on play with this one.

It means that the sever has to hold onto the reuslt set, which can be
quite large.
 
> There's one other alternative of course, but only if the store was created
> to your own specification (which makes me realize I only have a vague
> understanding of the various possible scenarios) :
> 
> (3) store the namespace (or at least some sort of integer key representation
> of it) along with the uri for each node in the repository as it's added.
> Then there's no latency or bandwith issues on the way out. However there
> might be other internal processing issues that would arise in the area of
> self-consistency and the like, and of course increased data size.

Thats what 3store v1 did, for prety much that reason, actually to
reconstruct RDF/XML cheaply. It was too much overhead though. Slows down
assertion and query.
 
> Our painful motto: No free lunch in computerland,

Too true

- Steve

Received on Wednesday, 2 June 2004 09:33:15 UTC