> Where do you think .ini files for individual modules should go?<br>First, seperate OpenSim's src and bin.<br>opensim/bin/OpenSim.exe<br> /OpenSim.Grid.GridServer.exe ...<br>opensim/lib/Nini.dll<br>
/libsecondlife.dll ...<br> /conf/OpenSim.ini<br> /mysql_connection.ini ...<br> /Regions/default.xml<br> /module/openid.dll<br> /loadbalancer.dll<br>
<br>in OpenSim.ini<br>...<br>Load "module/appearance_persist.dll"<br>;Load "module/openid_authentication.dll"<br>Load "module/load_balancer.dll"<br>Load "module/region_proxy.dll"<br>
...<br>If you do not want to use a module, you just simply ;(comment) it<br><br><div><span class="gmail_quote">2008/3/28, Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Where do you think .ini files for individual modules should go? Just<br> putting them in /bin seems a little messy - perhaps they should have<br> their own subdirectory (putting them with modules directly may make them<br>
hard to find, though perhaps that it also an additional option).<br> <br> --<br> justincc<br> <br><br> <br> Michael Wright wrote:<br> > Authentication is already quite modular , but in time hopefully it<br> > will be even more so. Its quite easy to write new login services that<br>
> use the login and authentication method of your choice. We<br> > (TribalMedia) do this all the time for various different applications.<br> ><br> > And yes opensim should always support walled 3d appplications. Its not<br>
> about trying to create one single metaverse that all use the same<br> > databases/methods/whatever. It is about creating a platform that can<br> > be used for lots of different things. The idea of a single shared<br>
> metaverse is one application, but separate 3d applications are just as<br> > important (and my main focus).<br> ><br> > So yes OpenID should be a option, but to me it should be that...a<br> > option and the only authentication system.<br>
><br> > There is never going to (or at least should never) be one<br> > "distribution" of opensim that mights all needs. We have tried to make<br> > opensim modular, so we should use that. And not try to add thousands<br>
> of flags to the ini file, but instead have the core and then the<br> > modules. With a ini file (or whatever) defining what modules are to be<br> > used. Different distributions of opensim could come with different<br>
> modules and a default ini file that loads those modules. So we could<br> > have a OpenID based distribution that includes the relevant modules.<br> ><br> > */Ryan McDougall <<a href="mailto:ryan@3di.jp">ryan@3di.jp</a>>/* wrote:<br>
><br> ><br> > On Thu, 2008-03-27 at 23:01 -0400, The Burnman wrote:<br> > > My concern, much like what Melanie stated, is that I do not want<br> > to be<br> > > forced to use a 3rd party service to use OpenSim. If OpenID is<br>
> not an<br> > > optional module, I will drop OpenSim from my toolset and move on to<br> > > something else.<br> ><br> > Well, this is open source, so in a very strict manner of speaking,<br>
> _all_<br> > modules are optional, so it kinda like asking if you can have your<br> > hamburger without a side of ice water.<br> ><br> > As for being _easily_ configurable to run without OpenID, I'm sure<br>
> that<br> > just a matter of:<br> ><br> > // in OpenSim.ini<br> > flag = false<br> ><br> > // in UserServer.cs<br> > if (flag)<br> > do_fancy_open_id_junk();<br> > else<br>
> ask_for_a_ridiculously_simple_name_and_password();<br> ><br> > So I don't think its remotely clear that anyone would be _forced_<br> > to use<br> > 3rd party stuff.<br> ><br> > > Aside from the idea of being forced to use 3rd party services, two<br>
> > concerns I have about using OpenID are:<br> > ><br> > > 1) Data security and integrity - With no control over authentication<br> > > or storage of related data, what's to say data won't be stolen or<br>
> > corrupted, thus causing my clients/users distress and thus<br> > causing me<br> > > a nightmare?<br> ><br> > Many issues here:<br> ><br> > 1. OpenID is a method of authentication, and optionally passing<br>
> identity<br> > preferences. It can enable portability, but in no stretch of the<br> > imagination _requires_ it.<br> ><br> > 2. Anyone who can read your data can copy or modify it. There is<br>
> no such<br> > thing as "data security" (ie DRM) in practice. If you don't want<br> > anyone<br> > to read your assets, don't put them on a publicly accessible server.<br> > Simple as that.<br>
><br> > 3. If your concern is integrity or authorization There are things such<br> > things as trust networks, digital signing, and whatnot, but thats not<br> > what OpenID is about and is a related but separate discussion.<br>
><br> > > 2) Service perpetuality (I might have made that word up) - What<br> > > guarantees OpenID will remain in business in a year, considering how<br> > > volatile the Internet business world is? How much downtime do I have<br>
> > to deal with because of maintenance or hardware failure?<br> ><br> > What guarantees _any_ website will remain up in a year?<br> ><br> > OpenID isn't a business, its a protocol with some implementations.<br>
> OpenID disappearing is about as likely as HTTP or Apache disappearing.<br> ><br> > > In fact, I don't know why people think OpenID is a good idea at all.<br> > > The whole concept is based on trusting a 3rd party to remain up 100%<br>
> > of the time, completely secure, and functioning efficiently. Using<br> > > OpenID takes any control of those variables out of my hands, and if<br> > > they have an issue, my service is offline.<br>
><br> > If you don't trust a 3rd party, you're able to run your own OpenID<br> > server with your own rules. That one will only ever go down if you die<br> > or the internet quits working. That's the Open part.<br>
><br> > > Sure, it allows some level of interoperability, but I don't consider<br> > > it worth the risk for my projects. Just do a Google search for<br> > > "OpenID security" (or similar search parameters) and read about the<br>
> > concerns a lot of people have about OpenID.<br> ><br> > I'm sure OpenID isn't a panacea, but as has been said repeatedly,<br> > no one<br> > is suggesting it be required for all people using OpenSim.<br>
><br> > Cheers,<br> ><br> > > On Thu, Mar 27, 2008 at 9:33 PM, Ryan McDougall wrote:<br> > > My understanding is that, like OpenID is currently used on the<br> > > web,<br> > > which is you could use OpenID if you have one, or the<br>
> > old-fashion type<br> > > if you don't.<br> > ><br> > > However, with OpenID > 1.0, it is possible to add attributes,<br> > > so OpenID<br> > > in OpenSim is a means of avatar portability, since one of the<br>
> > attributes<br> > > would be a URL to where your avatar can be found.<br> > ><br> > > That can't be done the old fashioned way.<br> > ><br> > > What specifically is your concern about OpenID?<br>
> ><br> > > Cheers,<br> > ><br> > > On Wed, 2008-03-26 at 23:57 -0400, The Burnman wrote:<br> > > > And I take it we are still on the "optional module" page in<br>
> > reference<br> > > > to OpenID, yes?<br> > ><br> > > > _______________________________________________<br> > > > Opensim-dev mailing list<br> > > > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> > > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> > > --<br> > > Software Engineer<br> > > <a href="http://www.3di.jp">http://www.3di.jp</a><br>
> ><br> > > The opinions expressed herein represent those of the<br> > > individual, and do<br> > > not constitute company policy unless expressly stated.<br> > ><br> > > _______________________________________________<br>
> > Opensim-dev mailing list<br> > > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br> > > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> ><br> > > _______________________________________________<br> > > Opensim-dev mailing list<br> > > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> > --<br> > Software Engineer<br> > <a href="http://www.3di.jp">http://www.3di.jp</a><br>
><br> > The opinions expressed herein represent those of the individual,<br> > and do<br> > not constitute company policy unless expressly stated.<br> ><br> > _______________________________________________<br>
> Opensim-dev mailing list<br> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br> ><br> > ------------------------------------------------------------------------<br> > Sent from Yahoo! Mail<br> <br>> <<a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52418/*http://uk.docs.yahoo.com/nowyoucan.html">http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52418/*http://uk.docs.yahoo.com/nowyoucan.html</a>>.<br>
><br> > A Smarter Inbox.<br> > ------------------------------------------------------------------------<br> <br>><br> > _______________________________________________<br> > Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> ><br>
<br> _______________________________________________<br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Liu Xiaolu