An idea I just had to get out there before it dies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Just few quick thoughts: distributed systems like kubernetes and service fabric already implement rolling updates, i.e. update application components while the application is running (included is also rollback/failover strategy if things go wrong) if you want to make your own distributed functionality upgrade on the run you might send a "reference" to the new functionality instead of the actual code instructions. You could add some kind of "authorized store" containing validated code. The message receiver gets a reference to the function to use to process that message, if not already available locally it downloads it from the store (only from the authorized one). This way you could mitigate security risk and avoid to implement a complicated code validation strategy at instruction level. Again these are quick thoughts, I didn't spend much time to validate my ideas but maybe they can be useful to you... I guess that's the spirit of this forum
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Congratulations. You just invented (the worst bits of) Windows 10. :-( You know, the server sends messages to the client, that include new "capabilities" and "instructions". The only capabilities that can't be changed are the capacity for the server to totally screw up the client, and for the client to stick its fingers in its ears and reject the "messages". :sigh: :doh:
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
-
honey the codewitch wrote:
which instructions are available would be specific to whatever the server does.
That is still learning. Humans may be hard-wired to learn language (the "message definition" message), but no human language is universal; every language has some things that cannot be said in it.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Like what? *crickets* Oh. Right.
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Sorry to rain on your idea, but it's called grid computing, and has been around for at least 30 years now. Use of a VM is a tweak to the idea, but doesn't address all of the concerns. One that's missing off your list, is who pays for the hardware and electricity to run your VM? Most people want some benefit to themselves for letting you use their hardware. Doesn't mean it's impossible, for example people donate their resources to things like SETI and protein folding. However, when they get nothing from it, they don't like it (e.g. the bitcoin mining browser exploits).
I live in Oregon, and I'm an engineer.
-
Sorry to rain on your idea, but it's called grid computing, and has been around for at least 30 years now. Use of a VM is a tweak to the idea, but doesn't address all of the concerns. One that's missing off your list, is who pays for the hardware and electricity to run your VM? Most people want some benefit to themselves for letting you use their hardware. Doesn't mean it's impossible, for example people donate their resources to things like SETI and protein folding. However, when they get nothing from it, they don't like it (e.g. the bitcoin mining browser exploits).
I live in Oregon, and I'm an engineer.
patbob wrote:
One that's missing off your list, is who pays for the hardware and electricity to run your VM?
I think your thinking of something like the JVM or CLI, not something like a Pike VM, which is a microvm that accepts a very limited instruction set suited for it's particular purpose, not general programming. Because the instructions are geared for what the service does, how much extra overhead the VM causes really depends on how crappy you designed your instruction set. It's a special purpose, not general purpose VM, and being dedicated, the inefficiency on introducing one is reduced considerably. Of course, it wouldn't be appropriate to use such a technology in all places.
Real programmers use butterflies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Sounds great. You can do the debugging!
-
patbob wrote:
One that's missing off your list, is who pays for the hardware and electricity to run your VM?
I think your thinking of something like the JVM or CLI, not something like a Pike VM, which is a microvm that accepts a very limited instruction set suited for it's particular purpose, not general programming. Because the instructions are geared for what the service does, how much extra overhead the VM causes really depends on how crappy you designed your instruction set. It's a special purpose, not general purpose VM, and being dedicated, the inefficiency on introducing one is reduced considerably. Of course, it wouldn't be appropriate to use such a technology in all places.
Real programmers use butterflies
Doesn't matter what the code is, or what it runs on, there's still a hardware cost (physical electronic circuitry) and electricity cost to running code. You simply cannot escape thermodynamics.
I live in Oregon, and I'm an engineer.
-
Doesn't matter what the code is, or what it runs on, there's still a hardware cost (physical electronic circuitry) and electricity cost to running code. You simply cannot escape thermodynamics.
I live in Oregon, and I'm an engineer.
LOL, if it's really a big deal, let's write all of our services in unmanaged code, throw .NET away, PHP? gone. No more java, node.js. Nothing. Hell, C++ is too inefficient, let's code the entire thing in assembly.
Real programmers use butterflies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Look into agent frameworks, especially autonomous agents. [Software agent - Wikipedia[^] I played around with the concept in the early days of the internet.
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Sounds like CORBA, or some kind of offshoot. Sorry if I'm way off on this - been retired a few years now. Around 20 years ago, or so, was looking at something like what you are describing. But at that time i didn't want to convert our systems to JAVA. perhaps by now Microsoft has caught up. Anyways, just disregard if not applicable. :)
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel