On Thu, Dec 19, 2002 at 11:50:46AM -0800, Ian Clarke wrote: > On Thu, Dec 19, 2002 at 05:58:23PM +0000, Matthew Toseland wrote: > > > > Um, no. > > > "Um, no" to what? There were a few suggestions in that paragraph. > > No, we cannot make splitfiles transparent by default. Because the user > > will not see ANY data transferred until we have a full segment with the > > current FEC implementation. > > Which is precicely why I suggested that we provide an alternate > mechanism, namely an Infolet, through which they can determine the > progress of their downloads. I think this is more elegant than some > kind of duct-tape Javascript/Frames arrangement as we had last time, if > you need me to explain why, then I am happy to go into more detail. There is no javascript required. And what is wrong with frames? We need to allow the user to configure it to be transparent, but with the current situation we absolutely must not have the user's first experience of splitfiles with freenet be clicking on the link and half an hour later cancelling it because it still hasn't downloaded A SINGLE BYTE, with no other immediately obvious feedback. > > > > What do you mean by "bring up" the GUI? > > Does it make more sense now? I mean the splitfile downloader interface. > > Yes. > > > > > I know. My question is, when will there be? IIRC we agreed that this > > > kind of functionality belongs in FCP. > > Eh? I never saw any such agreement, but even if we do agree that it > > would be a good idea to spec out live streaming, that does not > > automatically mean we need to support proxying it to any particular > > format in fproxy. > > I am not suggesting that we need to support any particular format in > FProxy, although it would be nice. As a first step, I am referring to > supporting it with FCP. > > > Additionally, I don't think it's very practical for > > the capture/insertion tool to be written in java, because it will either > > have to read continuously from the sound card, or integrate with > > something like icecast. > > If Python can do it (Fishtools), then I am pretty sure Java can do it > too. IIRC the protocols used by Icecast are fairly simple. The Java > code wouldn't read from the soundcard directly, rather it would > receive an incoming stream from some code which does (as does > Fishtools). This not-only gets around the problem of lack of microphone > support in Java 1.1, but is also more flexible. Java has pipes? It doesn't have symlinks, it doesn't have ctimes, it doesn't have disk space used... prove to me that java has support for pipes and I might take your argument seriously. > > Ian. > > -- > Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] > Latest Project http://cematics.com/kanzi > Personal Homepage http://locut.us/
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021219/35fa05fd/attachment.pgp>
