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@lists.cs.princeton.edu wrote:

From: Ge Wang <gewang@CS.Princeton.EDU>

Date: February 27, 2006 6:17:59 PM HST

To: ChucK Users Mailing List <chuck-users@lists.cs.princeton.edu>

Subject: Re: [chuck-users] file open semantics for clustered chuck

Reply-To: ChucK Users Mailing List <chuck-users@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!