Since the calculators memory is so small, is it possible to have a apache server host a text file with your basic in it and on the calculator type in your servers IP and it connects and executes the code on your calculator even if the code is too big to fit all on its memory. When it connects it would preload the first 1KB of the program and download more as it executed, while deleting the lines it has already executed, it would keep downloading ahead of time to keep it from slowing down but it would have a 1KB cache limit. Variables would not be ever deleted or strings however those wouldn't count against the cache limit, they would be stored somewhere less. That would allow theoretically infinitely large programs to be coded and the only limit would be 24KB of RAM available at a time. You could even load a program directly off cemetech.net you could have special html links that work in the DCS gCn web browser like <prglink> that would close the web browser and load the remote basic loader and start executing code!
I have run some tests and all is looking well!
Hooray for infinite memory!
I think there's more involved than you imagine. The calculator would have to communicate with the server, which the framework isn't in the OS for that. The OSwould have to tell the server which line it needs.
Additional complications come from constructs like For, While, Repeat, Lbl, and Goto, all of which depends on accessing code potentially far forward and backwards. At best, speed would be ridiculously low; at worst, it wouldn't work at all.
I agree with what Kerm said; and besides you'd have to completely rewrite the BASIC interpreter to handle the changing code (I believe that the calculator crashes if you attempt to run a program while editing it). Plus, you'd also have to include your connection handling in to the parser because the TI-OS does not support multitasking.
Long story short, the cons would outweigh the benefits. You're better off just trying to optimize your code to fit.
Yes, i agree that it would be painfully slow if it wasn't for the cache, there will be several new commands for cooperative multitasking, if the cached data runs low, >30 Bytes then it would pause every 2 commands to download more data until the cache goes above 50B. Also there would be available static sections. Static sections are parts of the code that are preloaded before the program starts. In a game, the pause menu could be put in the static section so the player doesn't need to wait for the pause menu to download, it would appear instantly as it is in the memory. Or in a platform game the level the player is currently on could be fully preloaded and cached before the level starts, that would allow infinite levels in a game. Frequently used gotos can be put in the static memory. That would solve the speed issue. Also downloading the basic data would solve the issue of updating your game to get new levels since the developer could simply update the web files and the game would instantly have all the new levels and features.
I'm afraid you don't understand the complexity of what you're suggesting. In order to implement your idea you'd need to rewrite the entire BASIC parser, which is a monumental task in itself. You'd have to first make it understand commands and then reimplement error handling. What happens if the calculator loses internet connectivity in the middle of a download? What if an infinite loop occurs?
As for your idea of updating a single file and having it automatically copy itself to older versions; that's optimistic at best. There still isn't a practical reason to connect your calculator to the Internet, and things like Chat and Gossamer are blown out of the water by the fact that you need a computer in the first place.
What this means is that nobody would really use this seriously. A better idea would be to make a package manager which can detect updates on a computer and download them to your calc, like what AHelper has done with GlassOS.