Code submission

[punt]

If one does updates/modifications/new modules, in the C++ arena, what are the ground rules?

For instance, does one have to conform to the UOX_PLATFORM concept? Can one modify that (perhaps that be the submission?). Does one have to worry about endian or 64 bit?

That is just an example, so the question is a general one. Or would it be just easier to keep the code base seperate?

An observation that few "concepts", goals, etc are documented about the project, other then move stuff to JS (but even that is not universal).

So in order to foster submissions, perhaps some type of overview?

[punt]

So I won't worry about submitting. Anyway, I was thinking one could potentially remove a lot of the platform dependcies by converting over the NSPR (threads,fileio, etc). The side benefit is this is what SpiderMonkey (js engine) wants if built for thread saftey.

My thought was getting this built under mingw, so it could truthfully be able to be a no cost option for windows users, as well as linux. So any other people who are interested in this, please post. I will setup a cvs somewhere I suppose for the effort.

[xir]

You quoted in a previous thread that a project would have to start out with using NSPR library at the beginning rather than it being introduced into a project in a mature stage. I think it would be a bit too much hassle to convert the whole UOX source to this library (and tbh why would you bother). However, the library offers a faster and more productive enviroment for developing rather than having to worry about inconsistancies within the code base as you port it to different platforms. Considering that there aren't many developers for UOX it would seem perhaps a feasible option and perhaps more productive in the long run. UOX has long held malformed code remnants left over from the "testbed" era (as the recent linux compilations have revealed.) Much of UOX is just a "hack" (just get it working) as to say with little structure to the overall design and the affirmation "leave it if it works" seems to hold true. Indeed the idiom "Too many cooks spoil the broth" comes to mind while thinking about how UOX was coded/designed in the beginning.

There would be little point in introducing this library to UOX unless a better design to the current came as a result. The main reason I'm thinking to introduce this is for threading, but what need has UOX for this in its current state? It has a thread for console and thats about it. Perhaps start from scratch with a better design in mind and what needs to be threaded etc. and base it on UOX would be a better solution. Moreover, this solution would force a reconsideration of what is really needed in the core considering that an averred step has been made to move to the threaded JS engine as recommended by Mozilla. The negative side is a lot of code will be lost as a result and it does look like you are just trashing it and starting again.

Anyway, this is just speculation and my thoughts on what seems logical to me, but I'm little experienced in such matters.

NSPR is http://www.mozilla.org/projects/nspr/reference/html/ - platform independant library that mozilla recommends with usage of it's JS engine (threaded). [for those who want the link]

[giwo]

I completely agree that UOX lacks quite alot in the sense of direction and standardization. Most of the issues I work on regularly are systems that were never designed to cooperate with other systems in the first place.

As for a "from scratch" approach, that is for the future and future developers. I personally feel that while the code can be somewhat fluid, the scripts and JS Engine should be as normalized as possible, to allow that which the user directly interacts with and works on to remain standard, even were the rest of UOX to be rewritten under them.

That said, my personal opinion would be to focus on pushing out to JS that which we desire to be there (that is, of course, up to those working on the project at any given time, I see that to be Commands, Magic, and Skills). This way in the event of a rewrite or a complete trashing of the source, we prevent a massive loss of code, instead keeping anything we have moved out to JS, and allowing us to focus the executable on doing only what it needs to do, leaving the rest to the JS engine and scripts.

Whatever the case, with college starting, I won't be active for much longer, at least not on a regular basis, so this piece of the puzzle is for those who are next able to contribute...

[punt]

Yes, I don't find the UOX code base has a reason to invest much time in terms of long term viablity, but I was not asking on a total restructuring.

I was speaking in much smaller terms, in what the preferences would be (clearly the dev can choose to follow them or not) for chances to UOX. It wasn't related to JS in terms of the specific, but was of interest to the general.

1. If a dev was to do some changes, what consideration do they have to give to platform? Is the expectation to follow the UOX_Platform concept? What is the consideration that should be given to compiliers on the same platform (since it doesn't appear UOX handles this currently, do others have to consider it)? Does one have to address endian issues in their code, or is UOX only concerned with small endian.

2. Given that for SpiderMonkey to be "threadsafe", one is suppose to use NSPR. Looking it over, it would appear that one could address many of the "platform issues", by converting over to that. So I personally was giving consideration to investingating that further, as a personal goal to get some experience with NSPR. As it would clearly not conform to the UOX_Platform approach the more I thought about it, it is clear any work in that area would not be consideration into submittal to the main stream.

3. Repeatedly I hear "moving out" to the JS engine. yet at the same time, one has identifed at least some things that are not to be considered (line of sight, accounts, etc). What should a developer consider are candidates? Are any candidates to be made as functions that can be called from JS (but still native C++)?


That is the scope of my questions. clearly a from scratch is more viable, but as those who might have an interest, was curious. As I considered the potential that the NSPR work might have been candidate for submittal, I was curious on the "desires", so I could at least consider them. But after more thought, it is probably not as critical, as I don't envision it ever conforming to anything that looks like the approach being taken to date on uox for cross platform.

[giwo]

As for platform and compiler compatability, that, really, is a topic more for an actual dev team, rather than myself individually.

That said, I feel compatability should be:

OS:
Win32, Unix/Linux primarily, every other OS a port

Compilers:
MSVC, mingw, gcc
Once again, any others would be a second thought or a port.

As for what will be in the JS

I foresee Commands, Magic, and Skills being fully in the JS engine, anything else is up to the people working on UOX at that time, but I don't see any need to step further than that at this point.

As for your thought of putting the Accounts system in JS, I've seen you state that a couple times, so I will reply my thoughts on why I don't see it as a likely candidate, at least not any time soon.

Accounts were just recently re-written, and are only now really getting fleshed out to working properly, why scrap that now? Secondly, accounts really don't need the level of customization that JS brings, and users (at least by-and-large) don't really require the ability to fiddle with them, past what should be possible by scriptability (ie the accounts scripts and the uox.ini).

As for other subsystems, of course any that do not need to be a part of the central core would be better put in JS (thus saving us maintenance work), but not doing so also shouldn't detract much from UOX as those in need of most customization (read above) will be in JS.

As for accessability and exposing internal systems to the JS engine, the idea, of course, is to allow the JS to modify or use the large percentage of the UOX core. Only that which truly doesn't need to be exposed should not be...

[punt]

As for platform and compiler compatability, that, really, is a topic more for an actual dev team, rather than myself individually.

At the moment , you and perahps Maarc are the dev team. Who else should be asked that an actual response could be obtained from?

That said, I feel compatability should be:

OS:
Win32, Unix/Linux primarily, every other OS a port

Compilers:
MSVC, mingw, gcc
Once again, any others would be a second thought or a port.

Ok, given that, I don't undertstand the UOX_Platform, it doesn't seem to allow for sublevel of compiliers on the same OS (mingw,msvc). So again,if one is to conform to that, how would that be done in the current construct?

As for your thought of putting the Accounts system in JS, I've seen you state that a couple times, so I will reply my thoughts on why I don't see it as a likely candidate, at least not any time soon.

Accounts were just recently re-written, and are only now really getting fleshed out to working properly, why scrap that now?

Just occurred to me, perhaps we are talking past each other. I wasn't asking for the dev team priorities, but was for consideration. In other words, if someone did it on their own, and submitted it , would it be integrated in, as if one did the same for one on your list. Now as to why one may consider it.
The same reason to migrate anything that is working into JS, to allow for user customization. And as you said, are still be flushed out, so why not fix them in the JS? Again, since it seems to be a user level thing, why would it be in the core? I can't think of performance, or other aspects to drive it in the core. But that is what I am trying to understand, is what is the criteria for being in the core, and not.

Secondly, accounts really don't need the level of customization that JS brings, and users (at least by-and-large) don't really require the ability to fiddle with them, past what should be possible by scriptability (ie the accounts scripts and the uox.ini).

Well, that was said for triggers at one time as well, so I guess it depends on who you ask. If one wanted to do database, a different file structure, additional checking on privs, etc, by being in the JS, it would expose it. And other then , "it was just done", I haven't heard why not. If that is the critiera, if applied evenly to other aspects of UOX, then I can at least understand. Otherwise I am at a loss to extraplate to some other subsystem that may not have been mentioned. I am not focussing on specifically accounts, but what is the ground rules for moving somethign versus not. You gave a list, one can assume then that is it ? Another way to ask, if one did a subsystem mod, to move something into JS (say accounts, or pick someother subsystem not on your list), is it a candidate into incorperation into the mainstream? How does one get a "feel" at least on this with out asking before one starts? By having some criteria, they could get a good feel for themselves, before starting. If not, then it is arbirtary, which again is the projects peragotive, but requires any outside developer to ask each time on each subsytem before they start.
And as a matter of curioustiy, given your answer, I really don't know if one stripped out the Account code, made a JS interface and scripts, if it would be considered for incorperation into the cvs.

As for other subsystems, of course any that do not need to be a part of the central core would be better put in JS (thus saving us maintenance work), but not doing so also shouldn't detract much from UOX as those in need of most customization (read above) will be in JS.

But that is the question!!!! what is the critiria for "needing to be a part of the central core"? That is exactly what I am asking, what do you use for that? Not trying to argue, or even debate. Trying to understand so one can use that to cover some othr subsytem that may not be mentioned. If it is just your list, and if others do something else, it wont be considered for incorperation, ok, at least it is understood.

Also, you didn't mention the concept of making a C++ core functions that can be called from the JS, and continue one (like a normal JS function, but c++). For instance, LOS would fall perhaps into that category. Is there any concepts like that can be exposed.

It isn't idle curiosity. I may have a few weeks that i will be homebound, and have a few moments to dabble in the UOX code. If I where to do that, I am curious what, if anything I did , might be considered for incorperation, before I start.

[giwo]

I would say the vast majority of things in UOX are not set in stone. That said, I would say that there really are no specific criterian for what will and will not go into the JS. I have created a list for the time being, those goals which I had hoped to accomplish (notably I was unable to complete moving even all of the commands out to JS, so much of that will be left to others).

As for what submissions are considered, in reality any would be. Though I would advise that most see less need for an accounts rewrite than other things which are more pertinent at this time.

On to the UOX_PLATFORM stuff, I really have had nothing to do with its incorporation, and can only say that it is incomplete as it stands.

Once again, what makes it into the "official" cvs (which notably I do not even have control over, thus my usage of OpenUO) is up to only the devs working on UOX at any given time. As for what gets released, anyone can release anything at any time with UOX, and any contribution regardless of viewed "importance" is typically made available to any who want it (IE through the script vault on this board), and generally would be a likely candidate to be included in the cvs builds, barring any major issues with it.

So if you feel the inkling to work on something.... do it, certainly won't hear complaints from me.

[punt]

As for what submissions are considered, in reality any would be. Though I would advise that most see less need for an accounts rewrite than other things which are more pertinent at this time.

I understand it is not on the dev teams priority list. Perhaps a better generic question I was asking, what criteria must be met for a submittal to be incorperated into the c++ cvs (and by cvs, I am referring to OpenUO, as that is the only active UOX development at the moment, with the other project being in affect inactive for the unforseeable future).

Basically, was there some areas that would be flatly refused. I take it by your answer no, all are equally considered.

Which leads to the other aspect. Clearly if one is writing to be incorperated , understanding the constructs of what the project is trying to accomplish is a crap shoot at best. That was what I was trying to understand.

On to the UOX_PLATFORM stuff, I really have had nothing to do with its incorporation, and can only say that it is incomplete as it stands.

Ok, so what is one suppose to do? If one writes a piece of code, and it needs to be different from mingw/gcc/msvc, can one just use __unix__ and some other home grown aspect? and let that conversion be the prolbem of the team when it gets submitted? the question was an attempt to reduce the amount of work by the team, but the answer doesn't give any insight into what an outside dev is suppose to do to aid in that.

Once again, what makes it into the "official" cvs (which notably I do not even have control over, thus my usage of OpenUO) is up to only the devs working on UOX at any given time. As for what gets released, anyone can release anything at any time with UOX, and any contribution regardless of viewed "importance" is typically made available to any who want it (IE through the script vault on this board), and generally would be a likely candidate to be included in the cvs builds, barring any major issues with it.

Well, as I stated, I am speaking to the OpenUO cvs, as that ist he only one that is an option at the moment.
I undetstand I can realise anything that I do , clearly I don't need anyone's permission for that. My question was more pointed, of how to get somethign one does incorperated into the cvs (again, not JS, but the c++). So the script vault is not applicable to what I was asking. I don't undestand the "major issues". Can you give insight to what that may be? Again, if a major issue is "I don't like how os platforms where handled, no need to move this subsystem into js, etc", that is what I am trying to undestand ahead of time.

So if you feel the inkling to work on something.... do it, certainly won't hear complaints from me.

Yea, but I was looking if there was anything I had to considered (and of course, then decide to abide or not), if I wanted what I did to be incorperated into cvs. That is the only purpose for the questions.

[giwo]

I'll meet you in the middle, punt.

Tonight I will work on a very rough with-only-my-thoughts-included attempt at stating how we will deal with different coding issues, and as to what standards are.

Moreover, I will write down some basic goals (once again, pretty much my thoughts and views, but we'll pretend for now that that's all that matters ;0 ) for UOX, allowing people to see where I personally would like the project to go, and know generally what I would be looking for in public contributions.

Hopefully in doing so it will make it more simple for people to be able to contribute, and give those who come after me an idea for where I saw UOX headed.

[punt]

I'll meet you in the middle, punt.

Again, this isn't to be a pain. To convince youself it isnt, say you are not on the team, but decide you want to do your favorite xyz addition/modification. Before you start, you want to know if it will be incorperated into the maintstream cvs. So you assume there is probably some things that should be done. How do you find that ahead of time?That really is the only intention.

If as you stated, all work is considered, and there really isn't standards, so that wont disquallify anything from being incorperated, that is good enough!!!!!! Nothing else is needed!

But if it isn't, then yea, any insight is always helpful!!!!

[giwo]

Ok, both docs are up at www.sourceforge.net/projects/openuo