|
From: | Benja Fallenstein |
Subject: | Re: [Gzz-commits] manuscripts/storm article.rst |
Date: | Wed, 22 Jan 2003 11:22:46 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |