- Thread starter
- #11
Well I started a bit or a discussion there, didn't I.
I suggested SQL for the main reason that TVServer uses it, so there was already an installation in the MP environment. Don't really want to install another database back end. If its there, why not use it?
Great ideas. Again, I just suggested SQL cause it was already there. What I was really getting at was exactly the design of a multi-client single data source setup. Using the current plugin on multiple machines, but linking to a single SQLite db3 file has issues that I have experienced first hand. It is not intended for multiple concurrent connections.
All the questions that fforde has put forward should be answered, no question. My personal setup of the plugin at the moment is all network shares, no drive letters, so that I can access my file on any of my computers. Everything is streamed and it works just fine.
What is possibly more obvious to consider, thinking about the way that MP, its skins & this plugin work at the moment, is how to handle the banners, thumbs, fan art etc that inker brought up.
My "design" preference would be to be able to assign a central location (network share or local for single seat) for these image files to be downloaded to and accessed from. I don't think MP or the skins could deal with that as currently designed unfortunately (please tell me I'm wrong). To cope with this current setup, potentially there would have to be a mirroring of these image files between "client" and "server" for a multi-seat setup. A function that could be initiated from the client plugin configuration for a first-time setup, then mirrored on launch from within MP. Still that is an issue that could cause delay on bringing up the screens. It gets more difficult. Avoiding duplication of files is one of the reasons that I suggested this in the first place.
Just had another design thought, but this is completely over the top. I've been dealing with getting applications running in a locked down Citrix environment lately and the have a wonderful tool called "Application Isolation Environment." This essentially provides a shell for the application to run in. If the application attempts to make a call to a specific location, you can configure the AIE to redirect it to somewhere else. The application is none the wiser. Cool concept, if only it were simple to implement and configure .... but it's not.
Just more thoughts on and off the topic.
I suggested SQL for the main reason that TVServer uses it, so there was already an installation in the MP environment. Don't really want to install another database back end. If its there, why not use it?
Great ideas. Again, I just suggested SQL cause it was already there. What I was really getting at was exactly the design of a multi-client single data source setup. Using the current plugin on multiple machines, but linking to a single SQLite db3 file has issues that I have experienced first hand. It is not intended for multiple concurrent connections.
All the questions that fforde has put forward should be answered, no question. My personal setup of the plugin at the moment is all network shares, no drive letters, so that I can access my file on any of my computers. Everything is streamed and it works just fine.
What is possibly more obvious to consider, thinking about the way that MP, its skins & this plugin work at the moment, is how to handle the banners, thumbs, fan art etc that inker brought up.
My "design" preference would be to be able to assign a central location (network share or local for single seat) for these image files to be downloaded to and accessed from. I don't think MP or the skins could deal with that as currently designed unfortunately (please tell me I'm wrong). To cope with this current setup, potentially there would have to be a mirroring of these image files between "client" and "server" for a multi-seat setup. A function that could be initiated from the client plugin configuration for a first-time setup, then mirrored on launch from within MP. Still that is an issue that could cause delay on bringing up the screens. It gets more difficult. Avoiding duplication of files is one of the reasons that I suggested this in the first place.
Just had another design thought, but this is completely over the top. I've been dealing with getting applications running in a locked down Citrix environment lately and the have a wonderful tool called "Application Isolation Environment." This essentially provides a shell for the application to run in. If the application attempts to make a call to a specific location, you can configure the AIE to redirect it to somewhere else. The application is none the wiser. Cool concept, if only it were simple to implement and configure .... but it's not.
Just more thoughts on and off the topic.
