dc3dreamer
Observatory auto s/w developer
- Joined
- Jun 2, 2009
- Messages
- 9
- Reaction score
- 0
- Points
- 1
This looks awesome. Thanks in advance for your creativity and hard work!
Project Common Orbiter Installation
- Thread starter Face
- Start date
Tommy
Well-known member
The more I think about this the more I see two potential problems.
1. Cross platform portability. Once the 2009 version is released, and OGLA matured a bit more, we'll see more and more people running on Linux. While the versioning system may be cross platform, how portable is the COI client?
2. This depends on the developers participation. It is possible not all devs will make their add-ons "COI compatible". Also, many older add-ons, whose developers are no longer interested, or unable to be found, will not be compatible. A system more like Portage would allow anyone to create an "e-build" type file (essentially just instructions for the add-on manager as to what the dependancys are, and where the files for that particular add-on can be found (address of repository)). This way even old "abandoned" add-ons could be included without repackaging the add-on and potentially infringing on anyones copyright. This could be very useful for add-ons that come with an installer, such as DanSteph's and Kulch's. When you select these add-ons in the client it would download the installer and run it.
It just seems to me that you are using a versioning system to do a package manager's job, but I certainly agree that a better way to manage add-ons is called for. Please don't think I'm trying to discourage you in any way, I just have the opinion that a package manager could be created that would do all this with less hassle for dev's and users both, and could be written in Java (or at least in easily portable code, perhaps using WxWidgets for the interface).
P.S. apologies for the run-on sentences!
1. Cross platform portability. Once the 2009 version is released, and OGLA matured a bit more, we'll see more and more people running on Linux. While the versioning system may be cross platform, how portable is the COI client?
2. This depends on the developers participation. It is possible not all devs will make their add-ons "COI compatible". Also, many older add-ons, whose developers are no longer interested, or unable to be found, will not be compatible. A system more like Portage would allow anyone to create an "e-build" type file (essentially just instructions for the add-on manager as to what the dependancys are, and where the files for that particular add-on can be found (address of repository)). This way even old "abandoned" add-ons could be included without repackaging the add-on and potentially infringing on anyones copyright. This could be very useful for add-ons that come with an installer, such as DanSteph's and Kulch's. When you select these add-ons in the client it would download the installer and run it.
It just seems to me that you are using a versioning system to do a package manager's job, but I certainly agree that a better way to manage add-ons is called for. Please don't think I'm trying to discourage you in any way, I just have the opinion that a package manager could be created that would do all this with less hassle for dev's and users both, and could be written in Java (or at least in easily portable code, perhaps using WxWidgets for the interface).
P.S. apologies for the run-on sentences!
I don't think this is an issue. First off, I doubt (that) many people will be running the thing in Linux anyway. Secondly, the core will never be able to run natively in Linux, so anyone running in Linux will have Wine or similar to run the core, and they can use that for the COI client.
Face
Well-known member
While I personally doubt your prophecy, there is always Mono for .NET applications. The complete OMP server is a .NET application running under Mono 1.2.6 on my private server in an UML on a 2.4 kernel with Woody(!), so I know that portability of .NET is just as good as of Java. Granted, UI-applications can cause headaches under Mono, but I'm sure I can get it to work once Orbiter runs on Linux without Wine
.No. It does not depend on developers participation. Developers are the natural source of addon-know-how, though. But every user can take e.g. DanSteph's installer, install it over a certain revision in his COI and add it as an addon to the private repository. He could share it, too. Besides license issues, it wouldn't be different to Dan doing it himself. Dan's repository - or his upload on a central server - would just be the more trusted source to get it. If he decides no one has the right to add it to a package-manager, he'll probably do so with every flavor of it. If he decides it is OK with one package-manager, but not with another, it is his decision after all.
One for the "e-build" file: thinking about yet another "language" to learn for addon-developers just to get their addon into a package-manager gives me the creeps. I haven't checked it in detail, but what I see tells me enough about the complexity of putting together and testing such a meta-data file. With a version-based system all you have to do is commit. No dependency list, no repository path, no instructions.
Right you are. But tell me, what defines a package-manager? And what is the job of one? IMHO, all you want are the right files in your directory, playing together to make it work.
Every package-manager I've used under Windows or Linux has problems doing this job. It was not only once that an installation was broken due to failure in Jones, aptitude, zipper, synaptic, whatyouhave... and this systems were developed over years, ever putting more effort into adding additional meta-data to get it right.
To be honest, I think every package-manager based on interdependence meta-data is flawed. If the filesystem-snapshot is what you want in the end, why not base the addon-system on this entity?
But I respect your opinion, so feel free to come up with a new package-manager written in Java with WxWidgets that is not broken by interdependencies in order to prove your point. Would be interesting how it performs time- and space-wise vs. a version-system based package-manager.
No need to apology. I'm always open for discussion (this is a forum, after all).
regards,
Face
Tommy
Well-known member
An e-build file hardly counts as "another language". For the purposes of COI it would likely be a simple text file, and could (depending on how you write the client) could be as simple as a listing of the add-ons (if any) requireded, and probably which "repository" it can be found at. It's actually far simpler than expecting a developer to get to know any particular versioning system's "ins and outs". Learning to write a "COInstall" file is probably no harder than learning a whole revisioning system.
Mono is acceptable. Sure it can be a PITA, but anyone who can set up Orbiter under Wine and OGLA can probably deal with Mono, so I doubt that would be a real issue. Sad truth is that most regular Linux users are used to jumping through these hoops. However, you say the server is .NET, but how about the client? Most Orbiteers aren't going to be running the server side. If the client is also .NET I don't see a real problem. For all it's weaknesses, .NET is fairly cross platform these days, and getting better.
No, he can't share it. Dan's license (as it exists today) explicitly prohibits re-distribution. "License issues" matter. I can't speak for Dan, obviously, and he may well be willing to allow re-distribution in this way, as long as he has control over which version of OrbitSound or UMMU is re-distributed. Or not, it's up to him, but Orbiter without OrbitSound is , well, not the Orbiter we know and love. OrbitSound is often taken for granted, as if it were a part of Orbiter itself, but it's not. Same goes for UMMU, which more than a few of the more popular add-ons depend on. I'd ask him how he feels about it before making any plans regarding his add-ons.
One has only to search the forum for all the "Why isn't Orbiter Cross Platform?" threads to see this coming. Those posts are the tip of an iceberg - for everyone who complains, there are dozens, if not hundreds, of people who simply ignore Orbiter because it can't currently run effectively under Linux (even with WINE). I myself only kept Windows for running Orbiter. EVERYTHING else I do on my computer I do under Linux. It's a measure of how much I like Orbiter that I keep 30 Gb of disk space, and maintain an OS, just for Orbiter. While I respect Martin's (and your) right to use the tools he chooses, and the OS he prefers, I'm simply pointing out that a cross-platform solution will help more people than a "Windows Only" solution.
Heilor said:
The fact that the Orbiter core can't run natively under Linux is irrelevant. The core doesn't rely on Microsoft propietary libraries (such as MFC) that a client MAY (don't know from what I've seen yet) rely on. Turns out that COI may be .NET, and if that's the case it's not an issue. I'm suprised that as someone who claims to use Linux, you are always one of the first to shoot down any suggestion that Orbiter may one day be used under Linux. That kind of prejudice does not speak well for your openmindedness. Just because you think Linux is only for servers doesn't mean you're right. I raised ligitimate issues, and Face presented legitimate arguments (and good ones, I may add) for his side. You have simply disrespected my point of view. Sorry, but you get no points for that. Your "Linux is only good for servers" mentality is not relevant to the discussion at hand. This is NOT another "Linux VS Windows" thread, so please do not go off-topic with your personal opinion about Linux's validity on my computer.
Face
Well-known member
It will certainly be a context-free grammar, if you try to deal with all possible addon merrits. Just think about adding lines to the base.cfg, or dealing with collisions, etc..
If it doesn't deal with all addon merrits, it is not worth to pursuit, anyway.
And trust me, it can't be as simple as listing addons... just think about versions of addons (see... "version" again).
The whole purpose of COI is to shield the developer/user from versioning system's "ins and outs". There aren't many, anyway...
As I said before, adding an addon in COI is a commit. Not creating a file and filling it with content and checking if it works in all possible conditions.
The more I think of it, the more I'm convinced that quite some folks will get a "Heureka!" once getting the concept...
Mono is in this regards equivalent to Java. Not much difference. Both are virtual machines, both need to be set up on a machine in order to use applications using them.
Please keep in mind that I talked about OMP server - not COI server - in the previous post. For COI, there is no server at all. For OMP, the client is .NET, too. As much as possible, ofc, after all it have to interconnect with a C++ application.
Technically, he can share it. If it is prohibited by law or not is something for lawyers, not technicians. With this system, everyone can distribute every file-system snapshot to everyone. There will be no central server that prohibits something. OFC, Dan can sue every evil distributor to hell, but he can't stop it technically.
The point is: there is no need for sharing it. Every COI-user can just download the installer, install it over a revision and commit it as addon to his private repo. And then use it together with "native" addons. No problem at all.
Disclaimer: I very much respect Dan's decision for not allowing distribution of OS by third party. I understand his points in this regards. So, sorry Dan for bringing you up as negative example in this discussion, it is no critism of your decision!
As for the Windows vs. Linux and why Orbiter should be cross-platform or open-source: I won't go that route in this thread - it doesn't belong here and is irrelevant to COI. I stay with my doubt that Orbiter will run natively on Linux anytime soon, and I stay with the comment, that COI is .NET and can be ported to run in Mono under Linux if the need ever shows up.
regards,
Face
EDIT:
Out of interest, I've looked on this... OMFG! This is using CVS, bash scripts and Python. I think every discussion about e-build as example is obsolete for me now...
Last edited:
tblaxland
O-F Administrator
I'm with Face on this one. Until a week ago, I had never used any version control system. I've spent very little time using Mercurial in that last week but I was amazed at how easy it was. As far as developer work flow goes, it is nothing more than a few mouse clicks (I'm using TortoiseHg, you don't need to learn any command syntax) to commit locally and push your addons to a online repo. That is actually easier for me to do than the usual business I have to go through to publish an addon (not a lot less work but more automated and less error prone). It is even easier again if I have used Mercurial to manage my addon during development also. All I can suggest is try it yourself (unless you have already?).
Sorry, I'd thought that COI being .NET was a given from the start, since Face is our resident .NET expert...
I will keep these points short and simple to avoid hijacking the thread further than we already have:
- I have never, ever said that Linux is only good for servers. Currently, that's where it's deployed most widely, but it's also a perfectly viable desktop OS for people who want a third alternative to the "big two." It isn't a valid alternative for me personally, because I'm a gamer.
- My problem with suggestions of having Orbiter on Linux is not the nature of the thing itself; I think that would be excellent and could only increase the user base. My problem is that many of the "suggestions" are often very forceful and phrased as "this needs to work on linux" or "why doesn't this work on linux, it's easy"
- The amount of development time needed to get a large existing project working on Linux is nontrivial, and in the case of Orbiter where there are limited development resources (Martin's spare time), I feel that those resources would be better spent elsewhere rather than making Orbiter accessible to the <3% of the population who uses Linux as their primary/only desktop OS.
Tommy
Well-known member
Technically, I can walk in to a bank with a gun, and walk out with a lot of cash.
My point wasn't so much about respecting copyright laws, as it is about respecting Dan's wishes. Chances are he wouldn't hire a lawyer over software he gives away (no ROI in it), but he may well stop developing for Orbiter, and that would hurt us all. But I think I misunderstood you, it seemed that you were talking about something along the lines of redistributing an "Orbiter with add-ons installed", and you've made it clear that that isn't the case. You aren't redistributing an environment, just the "instructions" to create an identical environment. I can't see any problem there at all.
I think I was also a bit confused by the way you present this a a "versioning system". The more I come to understand your plan, the more I see that you are creating what I consider to be a "Package Manager", even though you use the vesioning system as a "backbone". My apologies for my misunderstanding.
BTW, with Portage CVS is used primarily as a means of maintaining the repository. The purpose of the repository is to ensure that Portage can always find the app to download it, rather than reley on the dev's to maintain the package at the same URL. With Orbiter, the chance of files being "moved around" and lost is much less. It seems you've come up with a plan that doesn't require a central repository, which is fantastic. Maintaining a repository would require a lot of time from someone, and your plan will eliminate that. I guess my main objection was that using a full fledged versioning system for this is kind of like using a chainsaw to cut butter - overkill, and more complex than it needs to be. On the other hand, if it allows you to avoid re-inventing the wheel it makes sense. Dev's only would need to learn the subset of commands that COI needs, and not all the ins-and-outs, so it's not really significantly more difficult than learning to use a purpose-built PM.
Thank you for your patience with me on this, I guess I've finally had my Huereka moment.
Heilor, whenever someone dares to utter the L word here you exhibit a knee jerk reaction. Nowhere did I say that this NEEDS to run under Linux, only that it be useful to more people if it did. Nor did I advocate porting Orbiter - I'm much happier getting a new earth atmospheric model. It would be nice if Orbiter had been designed for portability from the start, but it wasn't. When Martin started Orbiter, Linux wasn't really a viable platform for this kind of thing. It had "ifffy" Open GL support, poor or non-existant graphics card drivers, and several different ways of handling sound. Joystick support was a joke. As you say, porting Orbiter now would require a massive effort that could be better spent elsewhere. With the NG core running relatively easily under WINE, and a native graphics client, there's not much point to it anyway. However, there is a huge difference between getting a non graphic app (such as the NG core) running under WINE than getting even the most basic GUI apps (even Notepad) to work. I wasn't aware that Face was the ".NET guru, and getting a .NET based GUI app to run under MONO is trivial compared to getting a non-.NET GUI app to run under WINE.
Nor have I ever advocated Open Sourcing Orbiter. The forking problem alone would make that a poor idea. I don't see any real advantage to it anyway. The OS model works for some things, but not all things. Next time please actually read my comments before reacting.
Let's just agree to disagree, and not clutter this thread with our personnal preferences as to OS, etc. I suspect you'll agree that the last thing this forum needs is another "Windows VS Linux" thread!
Last edited:
I'm not exactly known for giving long detailed explanatory answers, and that can often come across as rudeness; sorry. I'm also apparently not as good at keeping track of other people on the forums as you are, apparently
.Agreed, although those threads are so very much fun!
Tommy
Well-known member
I'm also apparently not as good at keeping track of other people on the forums as you are, apparently
Well, I didn't know Face was a .NET guru, so apparently I keep track of people no better than you! And yes, I also enjoy a good flamewar every now and then.
Face
Well-known member
Hm. It is true that I work on the tool and not on the redistribution, but my tool is encouraging sharing. Just like the gun-creator made the weapon you can technically use to rob the bank in your example above.
The system can be easily scaled up to OH terms...
Indeed. That was my intention...
...and there is no need to apology for misunderstandings...Face said:
I'd really suggest you take a closer look at DVCS and TortoiseHG especially. If you are used to CVS or SVN, you'd be surprised how easy it can be to version control. In addition, the concept of content-addressing and direct-acyclic graphs for storing revisions is a real eye-opener.
You are very welcome.
regards,
Face
---------- Post added at 08:09 ---------- Previous post was at 08:03 ----------
BTW: TortoiseHG 0.8 with Mercurial 1.3 is out. It now supports sub-repos and the GUI has been redone to better fit into Windows.
Face
Well-known member
another update...
Remote database readout is finished. I added some state icons for addons, that are:
So loading the local COI would give you this:
As you can see, there are no state icons, because no compare to a remote COI is done yet.
After loading the remote COI, the state may be like this:
You can see 3 types of icons here:
The next screeny show what happens if various selections are made and process is clicked:
Notice the progressbar at the bottom and the status messages.
regards,
Face
Remote database readout is finished. I added some state icons for addons, that are:
- new on the local side,
- new on the remote side,
- edited on the local side (i.e. a upload would overwrite the name, user or version entry for the addon, but not the addon content)
- edited on the remote side (like local, but vice versa)
- moved on the local side (i.e. name, user and version has been placed to another revision, indicating changed content)
- moved on the remote side (again vice versa)
So loading the local COI would give you this:
As you can see, there are no state icons, because no compare to a remote COI is done yet.
After loading the remote COI, the state may be like this:
You can see 3 types of icons here:
- green arrow indicates new addon on either side
- pencil-and-paper indicates editing entry on either side
- folder-move indicates addon move on either side
The next screeny show what happens if various selections are made and process is clicked:
Notice the progressbar at the bottom and the status messages.
regards,
Face
Face
Well-known member
Another developement update...
I've added permanent storing of combobox content as well as tool options. The options dialog lets you enter program path and arguments for your prefered DVCS tool for log, commit and shelve.
The shelve tool settings are used already in the event of outstanding changes while trying to do a processing of selections.
If you enter Yes here, the appropriate tool will be started (it defaults to TortoiseHG's shelve tool)...
As soon as the shelve tool is closed, the system is examined again and will report if there are still changes.
If you click Yes, the tool is started again. On No, the processing continues, overwriting the changes. On Cancel, processing stops.
The XML file storing the data looks like this:
Next on the list... using the commit tool settings for the add dialog...
regards,
Face
I've added permanent storing of combobox content as well as tool options. The options dialog lets you enter program path and arguments for your prefered DVCS tool for log, commit and shelve.
The shelve tool settings are used already in the event of outstanding changes while trying to do a processing of selections.
If you enter Yes here, the appropriate tool will be started (it defaults to TortoiseHG's shelve tool)...
As soon as the shelve tool is closed, the system is examined again and will report if there are still changes.
If you click Yes, the tool is started again. On No, the processing continues, overwriting the changes. On Cancel, processing stops.
The XML file storing the data looks like this:
Code:
<?xml version="1.0"?>
<Settings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/Settings.xsd">
<Tools>
<Log Command="hgtk" Arguments="log --nofork" />
<Commit Command="hgtk" Arguments="commit --nofork" />
<Shelve Command="hgtk" Arguments="shelve --nofork" />
</Tools>
<Local Selected="true">S:\Development\Mergingtest</Local>
<Local>S:\Development\letmetest</Local>
<Remote>file://S:\Development\Orbiter</Remote>
</Settings>regards,
Face
computerex
Addon Developer
Wow, I just found this thread h:. This is some excellent work face! Only question: How do I update the state of my local orbiter installation to have this tool installed xD ?
h:. This is some excellent work face! Only question: How do I update the state of my local orbiter installation to have this tool installed xD ?
Face
Well-known member
Wow, I just found this thread
Thanks. How did your multiplayer test-project come out? Hope you got those socket bugs nailed down...
Well, since you certainly won't have a local COI by now, you've to resort to the windows installer package
. Otherwise the Koi would bite its tail, so to say...cheers,
Face
Face
Well-known member
More progress...
I've more or less finished the adding feature. I have yet to nail out some bugs regarding refreshing the database, but this is no big deal AFAICS.
This is my current COI:
The add button will open a dialog to enter the author, name, version and revision of the new addon.
It dynamically changes its caption to "Add", "Edit", "Move" and "Replace" according to the settings of the combo boxes:
The "Commit" button will start the commit tool specified in the options dialog.
In addition, the combo boxes dynamically narrow down the possible selections:
As soon as those bugs are found, the next release will be made. I'm still waiting for interested beta testers, though...
regards,
Face
I've more or less finished the adding feature. I have yet to nail out some bugs regarding refreshing the database, but this is no big deal AFAICS.
This is my current COI:
The add button will open a dialog to enter the author, name, version and revision of the new addon.
It dynamically changes its caption to "Add", "Edit", "Move" and "Replace" according to the settings of the combo boxes:
- Adding is always done on revisions without addon information
- Editing is done on revisions with addon information, where the info is not matching that of another one.
- Moving is done whenever an addon is moved to a revision without addon information.
- Replace is to be invoked whenever an addon is moved to a revision with addon information. The addon info of that revision will be lost.
The "Commit" button will start the commit tool specified in the options dialog.
In addition, the combo boxes dynamically narrow down the possible selections:
- The revision will change author, name and version automatically. This can be prohibited by pressing the "Lock" button.
- The author combo box will display all available authors. Selecting one will re-evaluate the name and version combo box.
- The name combo box will display all available addon names for the selected author. If the selected author is unknown, all available addons will be displayed. Selecting an addon will re-evaluate the version combo box.
- The version combo box will display all available versions of the selected addon. If the selected addon is unknown, all available versions of all availabe addons of the selected author will be displayed. If the author is unknown, all availabel versions will be diaplayed.
- The revision combo will update again if the log or commit button was pressed. This way, changes to the revision graph will be reflected.
As soon as those bugs are found, the next release will be made. I'm still waiting for interested beta testers, though...
regards,
Face
wehaveaproblem
One step closer
- Joined
- May 18, 2008
- Messages
- 913
- Reaction score
- 0
- Points
- 16
- Location
- London
- Website
- wehaveaproblem.wordpress.com
I'll happily test next release for you, Face. Just gimme a shout.
