Thread: Architecture Changes

What impact will this have on plugins? You said that it would be transparent to plugins but will it force a plugin to use this to communicate to the os (or any part of the computer) or will it just be "another tool in the tool box" for plugin development?

I'll imagine that having plugins communicate trough this to the os would help to maintain cross platform plugins but it could be hard to expose the full api for each os.

Originally Posted by Borte

What impact will this have on plugins? You said that it would be transparent to plugins but will it force a plugin to use this to communicate to the os (or any part of the computer) or will it just be "another tool in the tool box" for plugin development?

I'll imagine that having plugins communicate trough this to the os would help to maintain cross platform plugins but it could be hard to expose the full api for each os.

By transparent I mean that plugin designers wont be able to tell the difference. This only effects what happens inside the core, at a lower level then what plugins have access to. For example, you can still use the setVolume function exactly like before only now when you call it the core will relay that command to the service to take care of instead of doing it itself.

For security, plugins will not be able to access the service even if they wanted to.

Originally Posted by justchat_1

By transparent I mean that plugin designers wont be able to tell the difference. This only effects what happens inside the core, at a lower level then what plugins have access to. For example, you can still use the setVolume function exactly like before only now when you call it the core will relay that command to the service to take care of instead of doing it itself.

For security, plugins will not be able to access the service even if they wanted to.

My question is twofold: One, how will you stop the plugin from being able to directly access the service? Also does this mean that the plugin will have to go through the core for serial port, usb access, BT, tcp/ip (And with that, web access), and even for playing its own sounds? What about file system access?

Originally Posted by malcom2073

My question is twofold: One, how will you stop the plugin from being able to directly access the service? Also does this mean that the plugin will have to go through the core for serial port, usb access, BT, tcp/ip (And with that, web access), and even for playing its own sounds? What about file system access?

Well the first ones pretty easy but the second one is definitely going to be a challenge.

For the service, we use a single peer to peer connection which is only exposed internally to the core. Since the core connects to the service before any of the plugins are loaded theres really no way to gain access.

The second part is definitely a lot more complicated. Serial, net and file system access are all managed code so its fairly crash proof. We also have alot of functions in the framework to make the common tasks even easier, plus the data storage classes so no file system access is needed for most. Unfortunately, things like bluetooth or usb access will probably be unmanaged code and potentially unstable (one of the reasons im writing the bluetooth myself lol)

Originally Posted by malcom2073

My question is twofold: One, how will you stop the plugin from being able to directly access the service? Also does this mean that the plugin will have to go through the core for serial port, usb access, BT, tcp/ip (And with that, web access), and even for playing its own sounds? What about file system access?

This is what I meant with my question too...

Sounds cool to me. When I was first reading this I was thinking, "Oh god I hope he isn't making every plugin in it's own process/etc!" That would just be madness! This much seems to be simple enough, basically you are just separating the os specific stuff off away in another process so the core will just communicate itself and also relay stuff to/from the plugins but wont care what actual back-end it is talking too.

When you say "we" as in "we feel the benefits will far outweigh the disadvantages" who are you referring to?

Originally Posted by Extide

Sounds cool to me. When I was first reading this I was thinking, "Oh god I hope he isn't making every plugin in it's own process/etc!" That would just be madness! This much seems to be simple enough, basically you are just separating the os specific stuff off away in another process so the core will just communicate itself and also relay stuff to/from the plugins but wont care what actual back-end it is talking too.

When you say "we" as in "we feel the benefits will far outweigh the disadvantages" who are you referring to?

Myself and another developer I consult with....of course the decision is still open for community input but i really can't imagine a better way to do this.

Originally Posted by Extide

Sounds cool to me. When I was first reading this I was thinking, "Oh god I hope he isn't making every plugin in it's own process/etc!" That would just be madness!

yep, process isolation and natural inherited mutithreadedness is nothing but madness. Don't you hate it when you crash explorer.exe and your window manager, taskbar and file browser all get taken out with it cuz they are all one process? I don't.

Originally Posted by justchat_1

Myself and another developer I consult with....of course the decision is still open for community input but i really can't imagine a better way to do this.

Ah, it has just seemed like you were the only guy really doing significant work on this so far, I wasn't sure if there was someone else out there who was also contributing a lot, but more behind the scenes.

Originally Posted by kev000

yep, process isolation and natural inherited mutithreadedness is nothing but madness. Don't you hate it when you crash explorer.exe and your window manager, taskbar and file browser all get taken out with it cuz they are all one process? I don't.

Ah yes, there are pro's and cons to everything, but that particular scenario was a bit too much imho, as it seems you would be separating it that much for no reason other than to separate it that much, and as long as all the plugins are using managed code I don't see how it would have any advantages anyways. In any case I think the right choice was made.