This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> The protocol allows one to extend the functionality of a peer (by > defining new procedures in the peer) without having to revise the > communication specification. Using this you could reduce the > bandwidth between peers by creating high enough abstractions. The > caveat being that the core functions are sufficient. However with ffi > abilities even this can be got around. This is one of my favorite ideas. Does anyone remember NeWS? *sigh* One disadvantage is that new implementations of servers become pretty complicated, since the protocol is an entire language. Guile makes that easier, but... The server must ensure that the client doesn't chew on the server's CPU, but that's not too hard to limit. What seems hard to me is limiting the client's consumption of server memory; it seems too limiting to impose a fixed quota on the client --- what if the user sends a valid, but very large, request? I guess you could just force people to write clients that coped with that.