>So, a little more concrete: [snip]
Maybe I'm simply ignorant and/or deaf, dumb or something, but I've got some questions. Meta: I followed your publish/subscribe mails that went over devl-list but was not able to find the mail which describes the need for the proposed p/s system. * What is it for? * As you might have noticed, you were the only one that said something to this p/s proposal. Nobody (Ian once) said something about it. Maybe there are others that don't see the use of it and grind their minds? Tech: Okay, if I understood correctly, stream-participating nodes are built up and bound together like a tree lying above the network, linked together by a stream ID and a stream routing table for every stream that's crosing the node. If another node wants to participate, it is enrolled into the tree. If a message comes in, it is routed up to the root node, then all the way through the tree to reach all stream participants. * What are the security and anonymity aspects when subscribers span up a tree? Isn't that somewhat trace- or probeable? * There was a streaming test implementation in the old 0.4 aera made by fish featuring FECed chunks of data that were adressed like edition freesites (there was some additional meta IIRC). So you could skip within that stream, old unwanted parts of the stream would fall out of the network and new ones are inserted by the "sender" for all interested clients to be received as datachunks using the normal freenet data retrival scheme. What's the gain of this p/s thing? * Is this complex p/s architecture needed? Can't the functions be done with "pure" datamoving? * Are the datachunks cached and routed in the same way as normal freenet CHK data? * Why an additional tree-structure if ((n)ng-)routing exists? * How is routing affected by this "treerouting"? * Are those streams to be understood as "shoutcast" audio streams? as newsfeeds? as read-only filestreams? IRC-style streams? What are their main use and what are they geared for? bulk transfer? low latency? * What if the "alchemistic" (as you like to call such things) limit of 32 streams isn't sufficient? Why 32 anyway? Why not 65536 or +inf? or 4? * What if DNFs are common? or at least often enough to have the tree break into pieces having to Resubscribe over and over? Workflow: You seem to be using at least some of your valuable (you being the only one that is able to bring us 0.7) time on p/s. * What priority is it? Maybe this could be considered 0.7.2 stuff and get 0.7.0 running first? I hope you can ease my bogged head.
