Hi there,
At least usecases will be pretty important to show how to use opensim for other stuff than gaming, while gaming and using it for a creative and relaxing time are own usecases. Some of them will develop to business cases. To show, that opensim is mature enough and how to develop a solution to a demand, based on opensim as a technology we started with a first Usecase on http://www.rexdeveloper.org/wiki/index.php?title=UC-classroom-tactical-train ing . I expect to get 1 per 3 month period. All this (from my side) will only be things, where real life companys are interested to use this - and maybe even fund the needed development. At least the usecases should deliver knowledge back to the community, and where the commercial arrangement with the "customer" does allow - code should be opend, as well. I will have my first project meeting at the 6th of march and I am very happy about the possibility to show opensim to an organization that is not just 100 people in size. Cheers, Ralf ------------------------------ Message: 2 Date: Tue, 24 Feb 2009 04:23:03 -0500 From: "Frisby, Adam" <[email protected]> Subject: Re: [Opensim-dev] The Business Case for OpenSim To: "[email protected]" <[email protected]> Message-ID: <63fad4f222230a4ea79de9e8be664735056d2...@winxbeus19.exchange.xchg> Content-Type: text/plain; charset="us-ascii" You are going to have fun with this one. There's probably at least a hundred separate ones, depending on who you ask. OpenSim has a lot of commercial contributions, a lot of which are biased towards particular features that their implementations need. Our goal has been to create a platform flexible enough that we can accommodate all these together while still sharing enough 'common ground'. Adam From: [email protected] [mailto:[email protected]] On Behalf Of Colin B. Withers Sent: Tuesday, 24 February 2009 1:15 AM To: [email protected] Subject: [Opensim-dev] The Business Case for OpenSim Hi, I have been thinking about writing a Business Case for OpenSim. A Business Case is the feasibility study performed before a full Business Plan is written, and is equally applicable to opensource 'products'. If such a Case has not been written before, then I would be prepared to write one, if the core developers would like one. But beware, it could be quite tough. As for credentials, I used to write business cases and business plans for News Corporation. Let me know, Rock MSc, MBA -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/opensim-dev/attachments/20090224/876401e5 /attachment-0001.html ------------------------------ Message: 3 Date: Tue, 24 Feb 2009 10:58:58 +0100 From: Stefan Andersson <[email protected]> Subject: Re: [Opensim-dev] User Authentication To: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Dear colleagues; for some time now, we at Tribal Media have employed an entirely different way of logging the viewer in, with tokens, that does not constitute changing the viewer. What we do, is that we install a 'launcher' app on the users computer. It serves a number of purposes: 1) Installs rezzme, genesis and osurl url monikers, all of them taking tokens as auxiliary data - these monikers let people log onto web sites, and launch a viewer with a pre-authenticated token by a link. (see step 5) 2) Identifies installed viewers, and keep track of preferreed viewer. 3) Provides a pre-login login form to do non-web pre-launch authentication (in this case, this would probably be where the _form_ obtains the token to pass to step 5) 4) Launches pre-requisite software, as the TribalVoice.exe for when voice should be enabled, or a Proxy to divert certain packets. 5) Launched preferred user, with seamless login (using the login option of the ll viewer with dummy data to bypass the login screen) supplying the TOKEN in a tweaked LOGINURI - an example of this loginuri would be -loginuri http://{loginserver}/?token={token} - have a look at the login service, it has been providing overloads and aux data for some time now, just to be able to do this. 6) Provides for hypergrid cross-login by providing both loginuri and target region as endpoint. While we might not want to provide all these options in OpenSim, I think our approach has worked well for us and our clients. Most of the code for these options are actually already out there in various scattered projects. Best regards, Stefan Andersson Tribal Media AB Date: Mon, 23 Feb 2009 14:31:25 -0800 From: [email protected] To: [email protected] Subject: Re: [Opensim-dev] User Authentication Right. The constraint here, let's not forget, is that we want to continue to reuse the LL viewer for a while. I'm going to read that doc about OpenID tokens, but if it requires participation from the viewer, forget it... We are and will continue to be in LL Viewer hacking mode in the foreseeable future, abnd I want to make things safe before a better viewer comes along. The bottom line question in my email, phrased in OpenID terminology, is whether we can use the Viewer's IP address as the token. Tommi Laukkanen wrote: As we cannot change the viewer at the moment one could use the opensim login code to create the token... regards, Tommi _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/opensim-dev/attachments/20090224/adc08ed1 /attachment-0001.html ------------------------------ Message: 4 Date: Tue, 24 Feb 2009 11:10:18 +0000 From: Melanie <[email protected]> Subject: Re: [Opensim-dev] script states To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed We have never made an incompatible change to the script states format. I fully intend to not break it.That said, it doesn't belong in a database, IMO. Database storage makes it so much harder to autoclean and maintain them. Script crossing is already implemented and has been for a while. They get transferred properly in that case. Personally, I think they're fine just where they are. Melanie Frisby, Adam wrote: > Sim states can't be reliable preserved between updates at the moment, because if we make any form of API change in the script engine, the states are invalidated. > > Regards > > Adam > > From: [email protected] [mailto:[email protected]] On Behalf Of Ralf Haifisch > Sent: Monday, 23 February 2009 12:30 AM > To: [email protected] > Subject: [Opensim-dev] script states > > Hi all, > > right now script states are kept in a directory "ScriptEngines". > > Loosing script states is getting a little bit pain in the neck. Some script don?t start without a manual reset for unknown reasons, other scripts don?t get on their feet again by design. So you have always some people running around playing with scripts after an update that looses script state. > > If I update I am always somewhat unsure wether I should take this into new version or not- thinking about consistency and compatibility. > > Furthermore I have no clue, wether that will be the best place in future when sometimes region crossing for scripts or wearing scripted attachments and logoff / logon will happen. > > > Would it be possible to move the script states to central, or at least the region db ? > > > Cheers, > Ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev ------------------------------ _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev End of Opensim-dev Digest, Vol 18, Issue 127 ******************************************** _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
