[Opensim-dev] [ CommandServer ] Draft 1

Fri Oct 17 07:13:13 UTC 2008

I suggest that it would 
a) be a set of generic ACL service classes that is implemented by concrete acl providers, so we can take acl from various sources.
b) be the sane acl service classes that are utilized on every server instance.Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

From: adam at deepthink.com.auTo: opensim-dev at lists.berlios.deDate: Fri, 17 Oct 2008 01:12:30 -0400Subject: Re: [Opensim-dev] [ CommandServer ] Draft 1

I do think having a proper ACL system is a definite need. I would definitely want to be able to assign permissions to regions on a more granular basis (especially per-region permissions, etc)

Adam

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of LcSent: Thursday, 16 October 2008 9:00 PMTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] [ CommandServer ] Draft 1

it was not a reject, i tought a dedicated userbase would have been more safe but i get your point :)I will rewrite the  draft with that input then.SM

On Fri, Oct 17, 2008 at 2:17 AM, Melanie <melanie at t-data.com> wrote:
You misunderstood me. I know for a fact that the onus ofadministering a separate user base would turn a number of gridoperators I know off using it.There definitely needs to be a setup that takes all logins andlevels from the grid database and requires zero admin if people joinor leave, other than adding them to the grid (user server) database.I don't know why you would reject using the data that is alreadythere, but the option should be there for those who want it.Melanie

Impalah wrote:> Hi everybody:>> + 1 for the idea, this first. Opensim needs this command center like we the> air to breathe. I hate to use direct access to DB and dirty tricks to launch> comands.>> I have some suggestions, taken from Drupal CMS (http://drupal.org).>> The first are roles and permissions. Now, as Melanie says, it's hardcoded> but could be a good idea to take out that code and "give" the permission> info reading from some repository. Could be more levels than one GOD and> even every action in a region could be assigned to a concrete role. One> thing I think Opensim lacks is some flexibility into the hundreds of> harcoded parts.>> The second idea is a module for drupal I use frequently: Services (> http://drupal.org/project/services)> This module allows to use drupal framework from external services and using> whatever protocol (xml-rpc, htpp, REST...). The conversion from php is quite> easy and has come great things like uniques uuid by server.>> About commands... well, I had to do some services similar to the pretended> Command Center and found useful some Patterns, concretely "Command Factory"> (with its "Command Context" pattern). To create new commands is like a> children game.>> I hope my comments helped you...>> Greetings>>> 2008/10/16 Lc <lcc1967 at gmail.com>>>> well, in my mind, i wanted to use its own user system to reduce the risks.>>>>>>>>>> On Thu, Oct 16, 2008 at 4:50 PM, Melanie <melanie at t-data.com> wrote:>>>>> Hi,>>>>>> the user level is already in the DB.... godLevel and UserFlags.>>>>>> if ((userFlags & 0xff00) == 0x300) { This is an employee.....>>>>>> godLevel == 200 is a grid god. Lower god levels can be made to have>>> lesser powers.>>>>>> I believe godLevel should be ignored by this app unless the account>>> has employee status, allowing to use godLevel for things like>>> janitor powers (return any object) without giving them the keys to>>> the grid (we do this already).>>>>>> Melanie>>>>>> Lc wrote:>>> > here are some input about the CommandServer (CS) :>>> > Aim:>>> >>>> >>>> > The aim of this server is providing a unified HMI interface for all the>>> > OpenSim server, actual and future.>>> > Any operator(s) will connect to the CS and performed their operations>>> from>>> > it without connecting to the regular server.>>> >>>> >>>> > Modularity>>> >>>> > Each OpenSIm Server  should be written like a plug in. That will allow a>>> > more practicable CS extension.>>> > Each HMI should be a plug in (if doable)>>> >>>> >>>> >    - HTML based HMI>>> >    - Commandline based>>> >    - OSfunction based ...>>> >    ->>> >>>> > Parameters>>> >>>> > The CS will auto-determine the grid configuration by itself, using the>>> > GridInfo technology.>>> >>>> >>>> > Database>>> >>>> >>>> > The system could use sqlite to maintains its user/level/access database>>> >>>> > User Management>>> >>>> > Each user will have rights associated to its profile like:>>> >>>> >>>> >    - grid manager (full right)>>> >    - region manager>>> >    - user manager...>>> >    - ...>>> >>>> > This project will be on Forge.>>> >>>> >>>> > As usual, any idea, comments are welcome.>>> >>>> > Laurent, AKA Sacha Magne>>> >>>> >>>> >>>> > ------------------------------------------------------------------------>>> >>>> > _______________________________________________>>> > Opensim-dev mailing list>>> > Opensim-dev at lists.berlios.de>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev>>> _______________________________________________>>> Opensim-dev mailing list>>> Opensim-dev at lists.berlios.de>>> https://lists.berlios.de/mailman/listinfo/opensim-dev>>>>>>>>> _______________________________________________>> Opensim-dev mailing list>> Opensim-dev at lists.berlios.de>> https://lists.berlios.de/mailman/listinfo/opensim-dev>>>>>>> ------------------------------------------------------------------------>> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081017/30fab300/attachment-0001.html>