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
honey the codewitch wrote:
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?
The first thought that crossed my mind when I read this was "ActiveX". I'll leave it at that.
-
honey the codewitch wrote:
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?
The first thought that crossed my mind when I read this was "ActiveX". I'll leave it at that.
:shudder:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
honey the codewitch wrote:
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?
The first thought that crossed my mind when I read this was "ActiveX". I'll leave it at that.
:laugh: To be fair they didn't use a VM but i hear you.
Real programmers use butterflies
-
Yeah. I know. But how else can we tell you we like you so expressively?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
You are so full of .... hot air
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
You are so full of .... hot air
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
OK - it's time you're given the facts of life. In this case, did you ever wonder why a phart stinks? ? ? ? ? ? ? It's for the benefit of those who didn't hear it.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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:
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?
In the Human world, this is known as "education", or "training". You are suggesting that we give the client computers an ability to "learn" - a non-trivial task. At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent. If you wish an adaptive system, i.e. one that improves as the capabilities of the client are upgraded, you will need a "send capabilities" message which would allow the client to communicate its capabilities to the server. If you want to get really fancy, you could have the client use a "message definition" message as well, which would allow it to educate the server about unexpected capabilities that it has developed. I'm unsure if that way lies madness or genius. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
honey the codewitch wrote:
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?
In the Human world, this is known as "education", or "training". You are suggesting that we give the client computers an ability to "learn" - a non-trivial task. At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent. If you wish an adaptive system, i.e. one that improves as the capabilities of the client are upgraded, you will need a "send capabilities" message which would allow the client to communicate its capabilities to the server. If you want to get really fancy, you could have the client use a "message definition" message as well, which would allow it to educate the server about unexpected capabilities that it has developed. I'm unsure if that way lies madness or genius. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent.
Yes. Also I wasn't talking about making it learn so much as giving the client software the ability to send remedial software to the server that it could run to perform a task - which instructions are available would be specific to whatever the server does.
Real programmers use butterflies
-
Daniel Pfeffer wrote:
At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent.
Yes. Also I wasn't talking about making it learn so much as giving the client software the ability to send remedial software to the server that it could run to perform a task - which instructions are available would be specific to whatever the server does.
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.
-
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.
Except the instructions are fixed. It could be adapted into a learning system.
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
I worked on a product that did this. The primary server downloaded code to access servers at run time, on a per-session basis. It took the form of opcodes in an interpreted language, running on a virtual stack machine. The access servers were also preloaded with "scripts" that the downloaded code could invoke, which reduced its size. This was an embedded system, so security wasn't an issue. It wasn't too complex, but a detailed spec didn't have to be written: it was proprietary, so however the access devices worked was the de facto spec. New access devices had to be backward compatible, which sometimes meant replicating the idiosyncrasies of the original access devices with regard to how the language was interpreted. All of this generally worked well, but you can add backward compatibility as a third problem if trying to do this for more complicated applications.
Robust Services Core | Software Techniques for Lemmings | Articles
-
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:
but what if you could send *code* in the stream, even across process or network?
I did a test case of that using Docker and Python, including the ability to do some basic UI layout, etc. I really liked the idea and it worked well - spin up a Docker instance, run the code, and after a period of inactivity or when the user logs out, kill the Docker instance. Given that one is working in essentially a VM, the only thing one has access to is one's own Linux instance, so I wasn't too concerned with security, haha. For example, you could, in Python, list the contents of the OS folders, etc., but I didn't really care. The impetus for this are those sites that let you run C# code snippets, and I was curious how they might do such a thing, especially given the security issues.
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulation -
honey the codewitch wrote:
but what if you could send *code* in the stream, even across process or network?
I did a test case of that using Docker and Python, including the ability to do some basic UI layout, etc. I really liked the idea and it worked well - spin up a Docker instance, run the code, and after a period of inactivity or when the user logs out, kill the Docker instance. Given that one is working in essentially a VM, the only thing one has access to is one's own Linux instance, so I wasn't too concerned with security, haha. For example, you could, in Python, list the contents of the OS folders, etc., but I didn't really care. The impetus for this are those sites that let you run C# code snippets, and I was curious how they might do such a thing, especially given the security issues.
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulationMarc Clifton wrote:
especially given the security issues.
There's always the possibility they're relying on .NET's Code Access Security feature to do the heavy lifting. It works pretty well. I could probably find out if I tinkered with the C# code enough to see what it let you do and what it didn't but it's work. ;P
Real programmers use butterflies
-
I worked on a product that did this. The primary server downloaded code to access servers at run time, on a per-session basis. It took the form of opcodes in an interpreted language, running on a virtual stack machine. The access servers were also preloaded with "scripts" that the downloaded code could invoke, which reduced its size. This was an embedded system, so security wasn't an issue. It wasn't too complex, but a detailed spec didn't have to be written: it was proprietary, so however the access devices worked was the de facto spec. New access devices had to be backward compatible, which sometimes meant replicating the idiosyncrasies of the original access devices with regard to how the language was interpreted. All of this generally worked well, but you can add backward compatibility as a third problem if trying to do this for more complicated applications.
Robust Services Core | Software Techniques for Lemmings | Articles
That's interesting. I like embedded stuff, and certainly that can either disappear security issues, or it can make them much worse. I'm remembering the radiation dosing machine decades ago that was multithreaded and overdosed and killed 3 people because of a race condition. At least if I remember the story correctly. It was taught to me as a lesson about multithreaded code. So I guess it depends on what it controls.
Real programmers use butterflies
-
That's interesting. I like embedded stuff, and certainly that can either disappear security issues, or it can make them much worse. I'm remembering the radiation dosing machine decades ago that was multithreaded and overdosed and killed 3 people because of a race condition. At least if I remember the story correctly. It was taught to me as a lesson about multithreaded code. So I guess it depends on what it controls.
Real programmers use butterflies
This was a very large embedded system, a telecom call server with tens of millions of lines of code if you added up all the product lines that used the same platform (and that could theoretically be built into one distributable).
Robust Services Core | Software Techniques for Lemmings | Articles
-
This was a very large embedded system, a telecom call server with tens of millions of lines of code if you added up all the product lines that used the same platform (and that could theoretically be built into one distributable).
Robust Services Core | Software Techniques for Lemmings | Articles
That reminds me of a plum creek project i consulted on. huge.
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
honey the codewitch wrote:
but what if you could send *code* in the stream, even across process or network?
Silverlight? Dunno. Maybe you could call it Flash?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
honey the codewitch wrote:
but what if you could send *code* in the stream, even across process or network?
Silverlight? Dunno. Maybe you could call it Flash?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I wasn't thinking anything quite that ambitious. Mostly the instructions would be service specific. A graphics rendering server for example, would have instructions to create new filters and such but they all deal in polygons, pixels and math. A DSP application might accept instructions to do FFTs or other operations to transform a stream. That sort of thing.
Real programmers use butterflies
-
Quote:
There are two problems with this - complexity security and security.
FTFY
- I would love to change the world, but they won’t give me the source code.
You beat me to it ;)
cheers Chris Maunder
-
:shudder:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
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 you want Erlang.
