Hello
Automatic OXP updating was mentioned a couple of years ago in this thread:
https://bb.oolite.space/viewtopic.ph ... ic+updates
Did anything come of this?
Is there a way to build updates into Oolite in a similar way to the way Firefox does it: i.e. a notification pops up? If not, how do I know when OXPs have been updated? It's quite important if there's a big bug fix.
Updating OXPs by clicking
Moderators: winston, another_commander
The best advice would be to keep checking these forums every few days (or hours if your really sad...) to see what updates and bugfixes are available.
Either that, or compile it under Windows, and using TortoiseSVN you can update the source code daily to get the latest version straight from Windows Explorer (providing you have an Internet connection of course - but then you wouldn't be here otherwise, surely?
)
Either that, or compile it under Windows, and using TortoiseSVN you can update the source code daily to get the latest version straight from Windows Explorer (providing you have an Internet connection of course - but then you wouldn't be here otherwise, surely?
)
-
Cmdr James
- Commodore
- Posts: 1357
- Joined: Tue Jun 05, 2007 10:43 pm
- Location: Berlin
Im not sure either of the replies so far really address your question.
The OXP source is not normally in the berlios svn repository, so building yourself probably does not help with your specific query.
At the moment there is no OXP management solution, and I think its quite a challenge to build one. We would either need a central database of versions (think windows update), or each OXP would have to know where to go to check for updates, and as it stands I dont think either is really viable.
There is another issue, which is easily fixed, I think many OXPs either do not have a meaningful version number, or it isnt systematically updated (Im sure I have seen some OXPs released as 1.0, then another 1.0 later).
I am not sure that there is a globally recognised versioning system for OXPs. I guess there should be a version.plist or something that is always there, and always contains author-name, date, version number, copyright and other stuff. I have rarely seen this kind of file, looking at the pirate-coves.oxp on my machine for example, I have no idea what version it is, and I dont think oolite community expects it. Without something like this, its kind of hard to know if the version you have is up to date, at least its hard for an automated system to know.
The OXP source is not normally in the berlios svn repository, so building yourself probably does not help with your specific query.
At the moment there is no OXP management solution, and I think its quite a challenge to build one. We would either need a central database of versions (think windows update), or each OXP would have to know where to go to check for updates, and as it stands I dont think either is really viable.
There is another issue, which is easily fixed, I think many OXPs either do not have a meaningful version number, or it isnt systematically updated (Im sure I have seen some OXPs released as 1.0, then another 1.0 later).
I am not sure that there is a globally recognised versioning system for OXPs. I guess there should be a version.plist or something that is always there, and always contains author-name, date, version number, copyright and other stuff. I have rarely seen this kind of file, looking at the pirate-coves.oxp on my machine for example, I have no idea what version it is, and I dont think oolite community expects it. Without something like this, its kind of hard to know if the version you have is up to date, at least its hard for an automated system to know.
-
Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
-
JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Frankly, I don’t want to even consider automatic installation or updating of OXPs while the legacy scripting system and AI system remain in their current form. They’re inherently insecure. I don’t know of a way to abuse them for anything worse than crashing Oolite, but the probability is very high that there is a way. This is also why I’ll be removing the JavaScript Entity.call() function before MNSR.
A possible fix for this would be to sandbox scripts and AIs, i.e. refuse to execute methods that are not on a white list. The issue then becomes to work out which methods are legitimately used by scripts and AIs.
For Oolite itself, the next Mac release will probably have support for self-updating using Sparkle, which is an easy-to-use ready solution. Linux stable releases installed via package managers should be updated the normal way for the platform. I don’t know what the proper thing would be under Windows; the idea of rolling our own does not appeal.
A possible fix for this would be to sandbox scripts and AIs, i.e. refuse to execute methods that are not on a white list. The issue then becomes to work out which methods are legitimately used by scripts and AIs.
For Oolite itself, the next Mac release will probably have support for self-updating using Sparkle, which is an easy-to-use ready solution. Linux stable releases installed via package managers should be updated the normal way for the platform. I don’t know what the proper thing would be under Windows; the idea of rolling our own does not appeal.
E-mail: [email protected]