Replied: Mon, 30 Apr 2001 17:01:24 -0400 Replied: "ahmet uyar" Return-Path: auyar@syr.edu Return-Path: Delivered-To: fox@csit.fsu.edu Received: from wkkxt16 (slip16.scri.fsu.edu [144.174.134.56]) by mailer.csit.fsu.edu (Postfix) with SMTP id 278CD23A04; Mon, 30 Apr 2001 12:32:09 -0400 (EDT) Message-ID: <003201c0d193$0d0f0620$3886ae90@csit.fsu.edu> From: "ahmet uyar" To: "Geoffrey Fox" Cc: "Gurhan" , "Hasan Bulut" , "mehmet sen" References: <200104270422.AAA62518@dirac.csit.fsu.edu> Subject: Mehmet's solution Date: Mon, 30 Apr 2001 12:31:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Mehmet's solution has the advantages of: a) no synchronization problem with audio, since we will not send a message to the server to start/pause the data delivery to the client(s). b) better quality since we will be able to buffer data, especially when doing shared display. To me this solution seems better, but for the may demo we may not be able to finish this implementation. So we can implement this solution later I think. Ahmet Uyar ----- Original Message ----- From: "Geoffrey Fox" To: "Ahmet Uyar" Sent: Friday, April 27, 2001 12:22 AM Subject: From Mehmet > > 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 > > > > charset=3Diso-8859-1"> > > > > >
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 > >