kumpelblase2 / modlab Goto Github PK

Right now we face a problem: we cannot identify, at runtime, if route X comes from plugin A or plugin B. Moreover, if plugin A registers route /test and plugin B registers the same routes, they'll collide and only the last registered one will work. The same goes for controllers. So we should prefix them in some way before we register them. However, this might raise another problem, as you can no longer access the controller globally with the single name, it would then end up as CommandspluginCommandController or something of the sorts.

Given I have the route /view/:id. When now a user requests /view/1 and the system denies access because he's not logged in, once he logged in, it redirects to /view/:id instead of the actual requested uri, /view/1

• Streamer starts / ends
• new subscriber
• submode start/end

more to come

Right now, plain HTML with bootstrap is used for the frontend thus it's not really existent yet and sailsjs for the backend. The question is, is this really sufficient and the most elegant way to do it? I looked around for frameworks which support or even push modular applications (because modlab will be one) and there are some which caught my attention. Some require more effort when it comes to providing client side additions, some less, but shine in other things.

• Actionhero.js : Would result in a nice backend, (looks) easily extendable, but would require more work for client side modules
• MEAN.io : Really good support for modularized front and backend. Backend is, however, just express and might end up getting messy
• total.js : Also supporting modules, does not provide a specific frontend apart from what is already in place.
• socketstream : Loading assets when needed, thus it could be used to allow for module loading when needed.

Hubot is nice, but it doesn't fully offer all the twitch related stuff. It works, but for it it provide me the things I want, I would need to heavily modify it and so there's no reason to stick to it in favor of just creating a custom wrapper for twitch-irc.

• Define needed steps
• Create controllers for steps
• Layouts for steps

Right now I just use bootstrap classes. This might work, but I would prefer having some standard classes that some elements are made of to better customize them by themes.

Twitch changed to websockets so we should too.

Right now, we have to explicitly give someone the permissions X.Y.Z,X.Y.Z2, X.Y.Z3, etc. . This is ok for most times, but what if we want to give that person/group all permissions under X.Y? Adding all sub-permissions is too much work, since we're lazy and want to keep things organized. So what do we do?

We give that person the permission X.Y.* whereas the * is a placeholder for all possible names. thus X.Y.Z would match, but not X.Y2.Z.

Also, X.Y.* != X.Y . X.Y would depict the main functionality, or just the fact that you can access something of that group, while the sub-permissions give more fine grained control over what can be done. Keep in mind, * is only a placeholder for one name. X.* does NOT include the permission X.Y.Z, however it does include X.Y.

Later possible additions:

• Add inversion symbol (e.g. ~). X.Y.* in conjunction with ~X.Y.Z2 would result in the following: the person does have the permission X.Y.Z, X.Y.Z3, etc. but not X.Y.Z2. If this feature does not exist and you want to remove just one permission from a sub-group, you have to write out each sub-permission, except for that single one that he does not have.
• Add infinite placeholder symbol (e.g. **). Given a person would have X.**, he would then have X.Y, X.Y.*, X.Z, etc. , but again, this would not include X itself.

JWT -> JSON Web Tokens
We could use them to allow third party applications to access the platform if a user allows it.

You should be able to:

• View the rights of users/a user
• View the rights of a group
• Create a group
• Delete a group
• Add and remove rights to/from a user
• Add and remove rights to/from a group
• Add a user to a group
• Remove a user from a group

• Top bar
• Sidebar
• Themes (requires #36)

Things to change:

• Enable config loading again
• Test should no longer need to get run with lifted sails, just load sails

So either define load order or be strictly against it.