[chuck-users] Re: chuck-users Digest, Vol 7, Issue 22

[Jim Hinds]

Good analysis.  However, from a probablistic viewpoint the time-out  
problem is vanishingly small for a lightly loaded local network  
(that's why UDP works very well for machine control applications REF:  
sixnet protocol).

Pretty much give the perfomer the ability to get his files over to  
the server.  If he is really worried about time-outs, the logical  
thing to do is to structure those chuck scripts to load the needed  
files prior to starting the sound emitting spork-ettes.

Jim
On Feb 27, 2006, at 7:29 PM, chuck-users- 
request at lists.cs.princeton.edu wrote:

> From: Ge Wang <gewang at CS.Princeton.EDU>
> Date: February 27, 2006 6:17:59 PM HST
> To: ChucK Users Mailing List <chuck-users at lists.cs.princeton.edu>
> Subject: Re: [chuck-users] file open semantics for clustered chuck
> Reply-To: ChucK Users Mailing List <chuck- 
> users at lists.cs.princeton.edu>
>
>
> Hi!
>
>> Since an important usage mode for chuck is analogous to a server  
>> for multiple performers, I'd like to suggest that the file open  
>> semantics be extended.
>
> Great idea, though there are certainly more issue to consider for  
> remote operations, since they often aren't always as transparent as  
> their interface advertises.  For example, network timeouts when  
> retrieving a file need to handled.  Actually this seems to be part  
> of a similar problem of pre-loading/chunking sound files to avoid  
> interruption on large sound files.  So, we should probably add some  
> options to control load behavior.
>
>> By simply extending the semantics for Chuck's "open" from  
>> expecting a file name, I suggest that it be a URL instead.  If the  
>> filename starts with http:// or ftp:// or other legal prefix, give  
>> the URL to a curl library for access.
>
> Cool.  The .open function already examines the path to catch  
> "special" internal data (i.e. "special:glot_pop").  It would make  
> sense to extend that to URL.  We just need to find a way to semi- 
> gracefully deal with potential network timeout and lag.
>
> Thanks.  We shall look into this.
>
> Best,
> Ge!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20060227/276903b4/attachment.htm