Reply-to: Geoffrey Fox To: Ahmet Uyar Subject: From Mehmet Date: Fri, 27 Apr 2001 00:22:00 -0400 From: Geoffrey Fox Geoffrey Fox gcf@cs.fsu.edu or fox@csit.fsu.edu Phones Cell 315-254-6387 FSU Office 850-644-4587 FAX 850-644-0098 ------- Forwarded Message Date: Thu, 26 Apr 2001 11:01:15 -0700 From: "mehmet sen" To: Subject: some suggestions about replay This is a multi-part message in MIME format. - ------=_NextPart_000_0016_01C0CE40.369F4410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir, I have some suggestions about the replay option. I might miss some = details, but I feel like the following scenario will work and easy to = implement. At the request of the client divide saved Zip file into pieces (based on = Major events) Put them on the temporary files system. Use servlets to serve each piece, preferable keep them in memory as the = series of major event chunks. (Provide a primitive buffering system)=20 SMIL file will link all the pieces for the client. That way, 1) Replay will turn out into just on-the-fly file downloading. 2) Control will be in the hand of direct user client instead of our = implementation 3) Server will not get overloaded 4) Multiple clients can be supported. 5) Latency will be automatically solved by RealAudio buffering. (If = necessary other than audio, we can implement a client for this.) 6) Eventually we can add web page support such as visually present a = meeting as long clickable event series to any point like RealAudio bar. = Even annotations for each major event can be added later. ... Mehmet - ------=_NextPart_000_0016_01C0CE40.369F4410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sir,
I have some suggestions = about the=20 replay option. I might miss some details, but I feel like the following = scenario=20 will work and easy to implement.

At the request of the client divide = saved Zip=20 file into pieces (based on Major events)
Put them on the temporary = files=20 system.
Use servlets to serve each piece, preferable keep them in = memory as=20 the series of major event chunks. (Provide a primitive buffering system) =
SMIL file will link all the pieces for the client.

That way,
1) Replay will turn out into just on-the-fly = file=20 downloading.
2) Control will be in the hand of direct user = client=20 instead of our implementation
3) Server will not get=20 overloaded
4) Multiple clients can be = supported.
5) Latency will=20 be automatically solved by RealAudio buffering. (If necessary other than = audio,=20 we can implement a client for this.)
6) Eventually we can add = web page=20 support such as visually present a meeting as long clickable event = series to any=20 point like RealAudio bar. Even annotations for each major event can be = added=20 later.
...
Mehmet
- ------=_NextPart_000_0016_01C0CE40.369F4410-- ------- End of Forwarded Message