Re: [Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

Toni Alatalo wrote:
> +Storm limitations/weaknesses:
> +
> +- what, actually?
> +
> +antont ponders: for files storm is ok, but how about:
> +- irc? (latency?)

This is only a weekness if Storm is your hammer and everything must be a 
nail. ;-)

Although I admit I do have thought about doing chatting with Storm, at 
one Storm block per chat message. But this could be bloatful; I think I 
Storm blocks may simply not be suited to this.

What about latency? Storm is about blocks; blocks are a data structure, 
an issue I don't see as connected with latency. Things like the p2p/DHT 
stuff are particular implementations of Storm pools-- you do not have to 
use them with IRC if they don't work for that application.

> +- video? (throughput)

Same here.

Video *is* an intended application of Storm. There could be a problem 
with streaming, though, as you could not degrade quality to compensate 
for a bad connection because you need to check the cryptographic hashes. 
If you have a trusted server with a big pipe that does the id checking 
for you and sends you the lower-quality data, you could avoid this issue.

> +and:
> +.. multipoint live video? (both latency and throughput demands)

Live video would not sit well at all with Storm blocks, I should think.

> +* does it make sense to think of irc messages, and/or video frames, as
> +datablocks .. or what?

IRC messages: yes. Video frames: no. A longer piece of video would be a 
block. You would be able to transclude any number of individual framges 
from it xanalogically, though. (Video and audio, btw, is where the 
'media sharing' of Storm really pays off: you only need to store a video 
once even if you transclude it into many different sequences-- i.e., 
possible cuts.)

- Benja