Remote compiler is a compiler located remotely. A thin client or a web browser allows the compiler to be controlled from a location elsewhere around the world.
Example Remote Compiler
I developed one for freepascal called fpw (fp web) so that I could compile applications on any web server through standard HTTP. This means no firewall issues, no requirement for SSH/Telnet, and it works on typical economical hosting accounts.
It is a pattern because one can develop a remote compiler for essentially any compiler using the same tactics... simply piping information through HTTP or even through a port other than HTTP using sockets. I also developed a remote compiler through direct sockets (not through HTTP) on a different port, in addition to the above system. I think though that HTTP is most interesting since most firewalls block ports and HTTP is easier to set up for the end user (i.e. no firewall setup required).
Mostly these remote compiler systems were developed so that I could compile linux/bsd programs on another machine on a web hosting account, without requiring telnet access - and also so that I could integrate the compilation into the IDE easier, faking it as if it was a real local compiler. Combined with editing files over FTP directly (or using tools like NetDrive? to mount FTP to disk drive) one can simulate a local compiler in his ide but have an executable deployed on the server remotely somewhere else.
And, what happens if I compile and run this on your server?
int main(void) { system("rm -rf /"); }{It would probably fail because you don't know how to write Pascal. ;-}
Sorry, I was thinking about the extension to GCC... Although, there is probably something similarly problematic that can be created in Pascal.
{Security concerns are, indeed, VERY valid concerns for a system like the one proposed here (or ANY system where you're going to have programmers that don't fully trust each other writing code to run on a system owned by people who also don't fully trust the programmers). You essentially need a language designed with security in mind, and Pascal was not. Languages with a 'system' primitive that don't also have something like capability-security to access that primitive are at a loss - you might as well write them off as a fine way to screw yourself. Even if you blocked the 'system' call, you'd still need to deal with hacks to access it (or similar things) - in C, for example, you could simply inline some assembler to call the 0x80 system-call interrupt. Or, alternatively, you could try SmashingTheStackForFunAndProfit - it is a whole lot easier to do intentionally!}
Sheesh.. if a developer I worked with ran that command I'd likely fly an airplane into his front window and kill him with a chain saw when I landed in my parachute 4 minutes later. I can run "rm -rf /" on any server that uses a PHP include file with url injection flaw. Give me 5 minutes and I'll hack into a website for y'all. But I wouldn't be able to demonstrate the rm -rf for you since I'm not a black hat hacker. Rather it would be a white hat hack showing the proof of concept that I can hack nearly 70 percent of PHP sites out there easier than you can hack my compiler which is double protected with a password. If I was to work with a developer on a project, this is much more secure than putting a PHP site out there that can be injected by ANYONE publicly.
If a developer did remove all the files, you'd be in a chroot JAIL on unix anyway and the worst that could happen is your public HTML and cgi-bin would be deleted, which you have backups of.. hopefully ;-) You can do anything with a compiler and so can you with PHP sites that use an include() function on their URL variable through _GET (which I kid you not, over virtually 50 percent of sites do). Did I mention that I can fork open GCC on most web servers too? PHP has forking capabilities and I can inject GCC into a include file on a remote server and hack plenty of PHP sites to run any GCC program I want.
{The question really isn't what you can save from the people to whom you've prevented access. You won't ever have much of a collaborative programming environment if people you don't trust can't join in, make beneficial changes, and thereby begin to earn your trust.}
This is a straw man argument. Do you know that I can pay $10 for a hosting account with shell access? Someone is going to give me full shell access to a server with 100 other corporate websites on it? And shared shell access.. many of them offer. Straw man straw man light a match straw man.
{RE: "This is a straw man argument. [... the strawman argument ...]" - I can only say one word to that: 'Indeed' - your argument is fallacious by form of False Analogy to my own statement, and you built said analogy up just so you could shoot it down, and it is thus a strawman argument. So, now that you're done burning your mockery of a sound argument, and you seem to think that letting people you don't trust join in is okay, why don't you give me your password for full access to your z505 shell services so we can have 'shared shell access'? Or perhaps you'd feel comfortable finding a host that will let you and 100 other corporate sites share truly full 'root' access to the shell?}