As I have said before, PRISM really is meant to be installed under the LFS directory, in a sub directory called addons. This is so that PRISM can make use of configuration files that LFS has, and to make use of any assets that LFS uses (Like the path files, or AutoX layouts.) The point of this being not only to make addons clearer, where things like Airo would be installed to $LFS/addons/Airo/ and PRISM would be installed to $LFS/addons/PRISM, it also give us access to LFS directly.

Knowing where LFS.exe is very helpful to PRISM when used on the same computer as the LFS instance. It give us direct access to the configuration files, allowing us to read and parse this data. This means that, as long as PRISM is installed correctly into the $LFS/addons/PRISM directory, PRISM, in the coming versions, will not require any configuration at all. It will simply work with LFS. You don't need to give it any passwords, or anything of that nature, as it has access to that already in the config files. You don't need to setup the hostname, or tell it the InSim port, because it also has that information already. It will just work. I think in many cases, this will get around any problems that people might have with installing PRISM on their computers and servers.

The only draw backs is that it will not configure the HTTP interface, or the telnet interface. But for people that don't use it, I don't see it being a problem. If I do add the HTTP interface to PRISM as apart of the NCN setup, then it would be on port 8080 as to get around the permission problem with Windows Vista / 7.

Quote from Dygear :

<snip>

Although this is nice, it brings me to worry about some things... How exactly are servers that have multi-LFS dedi's going to use PRISM? will we still be able to set up manually?

Quote from T3charmy :

Although this is nice, it brings me to worry about some things... How exactly are servers that have multi-LFS dedi's going to use PRISM? will we still be able to set up manually?

Most people will only want to use PRISM with just one server, I see that being the greatest use set. But the people like you, who have jumped on right now, are really power users, and so of course there will still be options available to you to setup multiple servers. Something along the lines of a question on if you want to load the settings from the detected LFS instance, or use them and add more, or ignore the detected LFS instance and setup a whole thing on your own.

On the subject of installers, I was thinking about this and how some installers cause some Anti-Virus programs to cause a false positive. This would be the case with NSIS when using the Built-in NSISdl plugin that I intend on using. The NSIS Wiki has a warning about this plugin giving a false positive. This is a problem as I've built up a reputation of providing safe applications used by many websites, on many servers, and now many clients. I feel that even the look of impropriety could tarnish that image.

The problem boils down to this. I want to make a installer / updater that uses PRISM's github as a means of keeping everyone up to date. But in order to do that, I would have to use the Built-in NSISdl plugin and that would cause some Anti-Virus plugins to say that my installer / updater in virus. Even tho this is a false positive, I don't like the idea of that at all.

Thoughts?

I think some sort of interactive configuration could be implemented for power users and basic users alike if they decided they wanted to use it versus the zeroconf methods. Also, as to the auto updating you could have PRISM or a launch script call a helper script that checks for updates and pulls them, this is easiest on a *nix system because it would require git as a dependency. I know the github team uses Amazon S3 and updates an exe file that is called every time there is an update. I will however look deeper into this problem, but those are some quick surface thoughts.

Quote from zenware :

I think some sort of interactive configuration could be implemented for power users and basic users alike if they decided they wanted to use it versus the zeroconf methods. Also, as to the auto updating you could have PRISM or a launch script call a helper script that checks for updates and pulls them, this is easiest on a *nix system because it would require git as a dependency. I know the github team uses Amazon S3 and updates an exe file that is called every time there is an update. I will however look deeper into this problem, but those are some quick surface thoughts.

Well, like some things I've seen, you could always include a git executable...

Also, there's always libgit2, but that would require a person to compile it for their PHP version.

Auto update would be very awesome. It was one of the corner stones of what I wanted to see in PRISM. Filur did something like that for his InSim app that he never released.

There are a few pure PHP implementations of git out there. https://github.com/patrikf/glip is an example.. It might need updating as it's fairly old (2 years), but it might be a start (or even sufficient in its dated state to open and clone a git repo.

Quote from Dygear :

Filur did something like that for his InSim app that he never released.

Quote from Dygear :

never released.

Well isn't that bloody useful then.

Quote from zenware :

Well isn't that bloody useful then.

That's why I prod him every now and again to release the source code.