Forwarded: Fri, 27 Apr 2001 00:22:00 -0400 Forwarded: Ahmet Uyar Return-Path: msen@anabas.com Return-Path: Delivered-To: fox@csit.fsu.edu Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by mailer.csit.fsu.edu (Postfix) with SMTP id E929823A20 for ; Thu, 26 Apr 2001 14:02:21 -0400 (EDT) Received: (qmail 17074 invoked from network); 26 Apr 2001 18:02:21 -0000 Received: from capricornus.hosting4u.net (HELO anabas.com) (209.15.2.36) by mail-gate.hosting4u.net with SMTP; 26 Apr 2001 18:02:21 -0000 Received: from hizmet ([66.47.65.114]) by anabas.com ; Thu, 26 Apr 2001 13:02:18 -0500 Message-ID: <001901c0ce7a$e3d59050$9865fea9@hizmet> From: "mehmet sen" To: Subject: some suggestions about replay Date: Thu, 26 Apr 2001 11:01:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C0CE40.369F4410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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--