Rearchitect ULib and ULX?

[Megiddo]

Spbogie had an interesting idea: Rearchitect ULib and ULX.

I got a few ideas from Samu that may or may not be helpful. Let's come up with ideas of what we'd want if were to do this!

• Redesign UCL:
  
  • Only support for steamids, no passwords (at least this would be our default implementation, allow for custom stuff)
  • Easier configuration -- this is a topic in itself
  • Verify identity with the steamid auth hook instead of at join

• Bring back the module to get rid of garry blocks? At least offer it as an 'addon'
• Drop .ini files and use lua-config files? lua makes for a wonderful config tool, easy to understand. Drop cvars as well? They're never used.

Anyways, this is a far out there goal, probably won't have enough time.[/list]

[Megiddo]

You should be able to deny a command to be usable on anyone but yourself (IE, tp only works on you), you should be able to deny specific parameters or limit commands (IE, ban someone for a max of a day).

[Megiddo]

More ideas...

View ULX as a language wrapper -- converting from a user language to lua. Lots of error checking involved.

Here's some pseudo code of a possible way to write commands for ULX:

Code: Lua

1. -- A function defined somewhere... ulx.Slap( (valid player) ply, (int 0-100)power, (bool)onlyUp )
2. -- Our command format in console... ulx slap ply power up
3. cmd = NewCommand( "ulx slap" ) -- Sets up the console command
4. cmd:SetFunction( ulx.Slap ) -- It will call this function with the args given below when a player uses it
5. cmd:SetParam{ arg=1, type=PlayerArg } -- The arg to pass to ulx.Slap is a player object, PlayerArg is an object that's used to verify valid user input (see below)
6. cmd:SetParam{ arg=2, optional, type=IntArg, max=100, min=0 } -- The second arg is an optional int with a certain range
7. cmd:SetParam{ arg=3, optional, type=BoolArg } -- The third arg is an optional bool
8.  
9. BaseArg = {} -- Base class for our *Arg classes
10. function BaseArg:accept( args, argv, options ) -- This is the first thing called for the class. Passes the whole argument string.
11.      if options.arg then -- If we specified we want a specific arg, pass it to our more specific function
12.           if not argv[ options.arg ] and not self.optional then
13.                return FAIL_REQUIRED_ARG_MISSING, "Not enough args (or better error somehow?)"
14.           end
15.           return self:acceptArg( argv[ options.arg ] ) -- This is the more specific function, to be defined by deriving classes.
16.      end
17. end
18.  
19. BoolArg = inherit_from( BaseArg ) -- Inheritance
20. function BoolArg:acceptArg( arg, options ) -- This should be pretty straight forward, called by the BaseArg function accept
21.      bool = nil
22.      validBool = false
23.      <code here>
24.      if not validBool then
25.           return FAIL_INVALID_ARG, "Not a valid bool"
26.      end
27.      return SUCCESS, bool
28. end

This is a completely different approach than what we're using now. This means that for functions like "ulx god", we have absolutely no implementation for it. We merely define how the user input is constrained and translated. Now, using this, how would we do more complicated functionality like "ulx banid" where we need to report who the person banning is? In this case, we use a special function to retrieve that information, like ulx.GetMostRecentPlayerToIssueCommand() or some such.



Another far-reaching idea that needs more thought:
* Handle special cases like keeping a reserved slot open for only on person in particular, or only allowing someone to target themselves with a command, or only able to use certain ranges on a command (like max ban a day).

[JamminR]

Now, using this, how would we do more complicated functionality like "ulx banid" where we need to report who the person banning is?

Why make it complicated?
In your code idea example, you have user/coder set parameters 1,2,3,4
Instead, have every function that gets created have a 'default' parameter list that shouldn't really be different no matter what else the coder may add into the parameter table.
Gmod lua Player hook functions for example almost always have parameter 1 as the player index. Though other parameters vary from function to function, the first is almost always player index that caused the hook.
I say we do something similiar if we ever go this direction. Using your code example, maybe a parameter 0 which is always the player calling the command.
Perhaps have more 'static' parameters, and instead make the ULX coder start at 10 to start adding they're own parameters.
1 = player who initiated
2 = ?
...
10 = coder set parameter #1
...

[Megiddo]

Do you have any input, Jay? How about we start on this and see where it leads us? I'm thinking we should approach this as a recode. Let's start simple and slow, laying a good groundwork to build off of.

How to handle logging has always been an issue with Ulysses, with it ending up that usually we don't log anything at all. I'm thinking that we could use a simplified version of log4j for this issue.

Maybe we should have I/O checking in the ULib functions? This is also something I've always debated, but we could base it off the log4j level... to do this simply (at least imo), it would be similar to my idea for handling the ULX commands. IE:

Code: Lua

1. function test( int, float, bool, player )
2.    ULib.checkArgs( IntArg{ int }, FloatArg{ float, min=0.0, max=1.0 }, BoolArg{ bool }, PlayerArg{ player } )
3.    ...
4. end

I used the func{} convention in the ULX idea above as well, but in case you guys don't know, it's just syntactical sugar for func( {} ). I think this works a lot better than a huge parameter list and it allows you to expand the available options easily. IE, on PlayerArg, we might add "mustBeInGroup='admin'" or some such, and this wouldn't affect any other places we're using PlayerArg. Plus it's self-documenting.

Another idea I've had kicking around my head for a while (and to show you just how low-level I'm thinking about this on) is to drop CamelCase and use underscores instead. Which do you guys think is more readable? I'm waaay open to suggestions on this one. Should we have any other particular naming conventions while we're at it? I strongly hold onto the belief that any classes, or more accurately for Lua, pseudo-classes, should start with a capital.

Yet another thing I'd like to see happen in a recode is unit testing. I hope you all know what this is, but in case you don't... wiki to the rescue. Unfortunately Lua isn't exactly conducive to this. I can't decide exactly how this should be done... should we keep the unit tests in the source file they're testing? Should we just have a <filename>unittest.lua for each source file? Either way, I'd want to strip out the unit test code for releases. Unit testing should also be as easy as executing a console command and seeing the results in a file (or console but it's always harder to read the console).

That's all for now.

If spbogie is still alive and reads this, I'd like your input on all this too.

[jay209015]

I've read over this a few times, and I agree in all this:

Redesign UCL:
    * Only support for steamids, no passwords (at least this would be our default implementation, allow for custom stuff)
    * Easier configuration -- this is a topic in itself
    * Verify identity with the steamid auth hook instead of at join

In my opinion, SteamIDs and names should be used as often as possible to keep the user friendly idea going.

Bring back the module to get rid of garry blocks? At least offer it as an 'addon'

     -This is kind of iffy being the fact that Garry will break something later on down the road, and unblocking his commands will soon become an endless list

Another idea I've had kicking around my head for a while (and to show you just how low-level I'm thinking about this on) is to drop CamelCase and use underscores instead. Which do you guys think is more readable? I'm waaay open to suggestions on this one. Should we have any other particular naming conventions while we're at it? I strongly hold onto the belief that any classes, or more accurately for Lua, pseudo-classes, should start with a capital.

    -I often use CamelCase and Underscores to define functions and variables. I really don't have a preference except that CamelCase is easier to type as it come slightly more naturally. As for readability, I think the underscores wins there  looking at something like: APromotion_User_Init      in contrast to    APromotionUserInit.

I also think that we should add functionality for players in the same group to have different levels of power for immunity Ex: Say you want a "Head Admin" in the admin groups, but don't want the other admins to be able to move him around. So perhaps have an immunity level like: ulx adduser jay209015 superadmin 1 10<- the 10 being the level of immunity, so if I did ulx adduser Megiddo superadmin 1 9 I'd be able to move him around and he could do the same.

I also think a small gui could be placed like your UTime, or even your UPS so that it displays your current user group, or team if UTeam is installed, with the corresponding colors.

On a security note, I think that superadmin should not be granted ulx rcon by default. I think it should be done in the configs with steamid. That way if an exploit does open up, someone wouldn't be able to do near as much damage without the rcon pass.

I like your thoughts on more logging. I think it would be cool do convert the logs to html documents, or atleast html syntax, so that logs could be uploaded and preformatted to your webhost in something other then plain text. I've done it before with admin, and player logging on my old servers before, and people really like it. It looked great in combination with UMotd.

I guess I'll take a little break for now. Perhaps next time I'll be a little more on topic

[Megiddo]

     -This is kind of iffy being the fact that Garry will break something later on down the road, and unblocking his commands will soon become an endless list

This just goes around garry completely, no fuss.

I also think that we should add functionality for players in the same group to have different levels of power for immunity Ex: Say you want a "Head Admin" in the admin groups, but don't want the other admins to be able to move him around. So perhaps have an immunity level like: ulx adduser jay209015 superadmin 1 10<- the 10 being the level of immunity, so if I did ulx adduser Megiddo superadmin 1 9 I'd be able to move him around and he could do the same.

Not a big fan of things that are constrained to ranges like that... can you think of an intuitive way to do it? Immunity is something I feel that we've never gotten right.

On a security note, I think that superadmin should not be granted ulx rcon by default. I think it should be done in the configs with steamid. That way if an exploit does open up, someone wouldn't be able to do near as much damage without the rcon pass.

I'm pretty strongly in favor of superadmin having full access. This makes configuration much easier. If you don't trust someone, you shouldn't be giving them superadmin access.

I like your thoughts on more logging. I think it would be cool do convert the logs to html documents, or atleast html syntax, so that logs could be uploaded and preformatted to your webhost in something other then plain text. I've done it before with admin, and player logging on my old servers before, and people really like it. It looked great in combination with UMotd.

If you look into the implementation of log4j, it easily supports this sort of feature. Would be great as a companion release.

-------

On another note, not sure what your time constraints are these days JamminR, or what your interest level would be... but how would you like to make the unit tests for our code? You'd basically be looking at the API we built, the I/O, and design cases that make sure it works as advertised by skirting the line between good and bad input. You'd also be giving it bad input just to make sure it recognizes it as bad... Let me know what you think.

Does anyone have any idea where spbogie is hiding these days?

[JamminR]

I'm pretty strongly in favor of superadmin having full access. This makes configuration much easier. If you don't trust someone, you shouldn't be giving them superadmin access.

I tend to agree with this.
Jay, though your concern of exploit is valid, if someone has enough exploit or knowledge to abuse, limiting ULX superadmin from rcon usually wouldn't provide much additional challenge. I don't know if you saw Axim's last exploit discussion with us at the Facepunchstudios ULX release thread, but it was a direct rcon access exploit that someone just decided to use in combination with ULX.

On another note, not sure what your time constraints are these days JamminR, or what your interest level would be...<tasks snip>...Let me know what you think.

To be fair and honest with the team, my 'Steam' time, with any game, has been very little.
Though the winter and spring are usually my 'motivational' time, I'm in a slump in many ways.
I'll do what I can, but I feel at this point in time my interest wouldn't be enough to test as rigorously as I (feel I) should.
I believe stress has me in a clutch right now I'm having trouble escaping from.

Does anyone have any idea where spbogie is hiding these days?

Tag Spbogie, You're it!

[Megiddo]

I've been thinking about this some more, and realized it completely goes against our 'striving for simplicity' motto. It does, however, help me get more familiar with professional coding practices (which is why I do anything Ulysses-related at all in the long run).

What do you think JamminR? Is it worth it?

It's a large framework for a small task. I'd like to say that this would be something other people would pick up on as well, but we all know that's a downright lie...

[JamminR]

<clip>
What do you think JamminR? Is it worth it?
<clip>
this would be something other people would pick up on as well, but we all know that's a downright lie...

That is an answer I find myself having trouble forming an opinion.
What would it complicate? The ability of an non-experienced coder to look at a portion of our code and make modules for it? (et al MrPresident, who's pretty much rewritten a game mode with experience much learned from ULX hacking?)
I myself would have to relearn how to do things probably. (never a bad thing, remember, I'm not a programmer but like what I learn)
I've never had OO programming. Though the rewrite doesn't seem like it would be totally OO'ed, you mentioned classes, and to be honest, I still don't fully understand what they are.
The ease of our command modular pieces now are understandable for me, and seemingly many others.

What is the end result wanted? That answer may help you decide.
I don't fully understand how rearchitecturing the entire system would accomplish the 3 UCL points from the original post.
I believe, if you end up not redesigning, that those could be done without an entire code base change.
Sure, some hacking to ULib.ucl would need to be done, but, without the need for the pseudo code base you suggested.

[Megiddo]

Finished the unit test framework and a couple of unit test suites. I think it needs a little better output presentation, but I'm really happy with it otherwise.

[JamminR]

Set up a repo or something so the rest of us can look and play?

[Megiddo]

It's in the regular ulib svn under branches.

[spbogie]

I agree with Jam on the issue with the commands and the calling player. Why can we not pass through the calling player to the command function and then follow that with the specified arguments. Or, if you really want to keep the arguments limited to only what the coder specifies, then add an arg type=CallingPlayer which just passes through the player who called the command.

With the specifying command parameters, is it really necessary to have arg=1, arg=2, ... for each parameter. Why not simply use a table.insert and have them added in the order it is called. I really can't see any reason for someone to need to specify the 2nd or 3rd parameter before the 1st. If you want to keep that functionality, then make both a SetParam (takes the arg number), and an AddParam (adds as next arg) function. If you're going to abstract it out to an OOP design then take advantage of that and simplify the member functions where possible.


For logging, I haven't really looked into the log4j thing, but on thing that I've always wanted to do with it is have it log using the default source logs so you could see what was happening from ie. HLSW. This would require the module to grant access to the IVEngineServer->LogPrint function but would be very useful when attempting to monitor the server remotely.