<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Hi there, talking with Ai Austin we decided to install a complete demo of Justin's moap with a full installation of Simian Frontend so folks can see the web on a prim dev.<div>Here are the good news :</div><div><ol><li>Avatar appearance now works fine with Snowglobe 2.0.1 !!! This is because the Simian ships a default_assets folder pointed by the demo installation of tonight ;)</li><li>You can register to the demo-MOAP here : http://95.110.224.250/GridFrontEnd/</li><li>Download Snowglobe last release and login with loginuri http://95.110.224.250/Grid/login/ (note the trailing slash !!!)</li><li>Current release is R13260. We will follow Justin's job everynight and install the newest release.</li><li>Join and test it hardly ;)</li><li>In the next days we will try to install all scalable modules (search, voice...etc) any help by devs for installation is appreciated;)</li><li>If any of u needs to load iar/oar to the demo server contact me</li></ol><div><br></div><div>Ty again Justin and ty to all of u devs !!!</div><div><br></div><div>Enrico Nirvana</div><br>> From: opensim-dev-request@lists.berlios.de<br>> Subject: Opensim-dev Digest, Vol 35, Issue 35<br>> To: opensim-dev@lists.berlios.de<br>> Date: Tue, 13 Jul 2010 19:17:28 +0200<br>> <br>> Send Opensim-dev mailing list submissions to<br>> opensim-dev@lists.berlios.de<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> or, via email, send a message with subject or body 'help' to<br>> opensim-dev-request@lists.berlios.de<br>> <br>> You can reach the person managing the list at<br>> opensim-dev-owner@lists.berlios.de<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of Opensim-dev digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>> 1. MOAP : avatar appearance works fine now (Enrico Ranucci)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Tue, 13 Jul 2010 19:17:24 +0200<br>> From: Enrico Ranucci <enrico.ranucci@live.it><br>> To: <opensim-dev@lists.berlios.de><br>> Subject: [Opensim-dev] MOAP : avatar appearance works fine now<br>> Message-ID: <BAY155-w38F0F96B17B0BA0028F2C58CB90@phx.gbl><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> <br>> <br>> Hi there, ty Justin for you reply. I found out avatar appearance working fine with Snowglobe release 2.0.0 and your moap. Also Web on a prim works fine ;)With 2.0.1 it does not work ;(<br>> Everyone is interested to test Justin's release, i'm running a demo stand alone where users can see Web On a Prim working (using Snowglobe 2.0.0)You can reach it using loginuri http://95.110.224.250:9020 and Test User qwertyuiop as First,Last,Password.If u need your account contact me, i will provide a valid user for u.Ty again to Justin and all opensim developer for making OS everyday more "cool"<br>> Enrico Nirvana<br>> > From: opensim-dev-request@lists.berlios.de<br>> > Subject: Opensim-dev Digest, Vol 35, Issue 7<br>> > To: opensim-dev@lists.berlios.de<br>> > Date: Mon, 5 Jul 2010 12:00:05 +0200<br>> > <br>> > Send Opensim-dev mailing list submissions to<br>> > opensim-dev@lists.berlios.de<br>> > <br>> > To subscribe or unsubscribe via the World Wide Web, visit<br>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> > or, via email, send a message with subject or body 'help' to<br>> > opensim-dev-request@lists.berlios.de<br>> > <br>> > You can reach the person managing the list at<br>> > opensim-dev-owner@lists.berlios.de<br>> > <br>> > When replying, please edit your Subject line so it is more specific<br>> > than "Re: Contents of Opensim-dev digest..."<br>> > <br>> > <br>> > Today's Topics:<br>> > <br>> > 1. Cloudy avatar on snowglobe 2.0.1 or sl2 (was Re: Opensim-dev<br>> > Digest, Vol 35, Issue 3) (Justin Clark-Casey)<br>> > 2. Re: [Opensim-users] OpenSim Roadmap (Justin Clark-Casey)<br>> > 3. JSON or XML for serialization in the OpenSim database?<br>> > (Justin Clark-Casey)<br>> > 4. compiling viewer-external with ubuntu 64bit (Marc Adored)<br>> > 5. Re: compiling viewer-external with ubuntu 64bit (Marc Adored)<br>> > 6. Re: JSON or XML for serialization in the OpenSim database?<br>> > (Impalah Shenzhou)<br>> > <br>> > <br>> > ----------------------------------------------------------------------<br>> > <br>> > Message: 1<br>> > Date: Mon, 05 Jul 2010 00:34:46 +0100<br>> > From: Justin Clark-Casey <jjustincc@gmail.com><br>> > To: opensim-dev@lists.berlios.de<br>> > Subject: [Opensim-dev] Cloudy avatar on snowglobe 2.0.1 or sl2 (was<br>> > Re: Opensim-dev Digest, Vol 35, Issue 3)<br>> > Message-ID: <4C311A96.8000409@googlemail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>> > <br>> > On 03/07/10 11:50, Enrico Ranucci wrote:<br>> > > Hi, there. I'm running the Justin's "moap" with a fresh mysql db. Web on<br>> > > a prim works fine but using snowglobe 2.0.1 or sl 2, avatar appears as a<br>> > > cloud. any suggestions ? (which viewer is using Justin for testing moap?)<br>> > <br>> > Hi Enrico. I'm using the SL version 2 viewer as well and see the same kind of problems with appearance. I believe this <br>> > is because OpenSim has not yet implemented support for the appearance/clothing layer changes seen in the version 2 viewers.<br>> > <br>> > Either these changes will be implemented in OpenSim at some point and/or perhaps one of the third party viewers will <br>> > implement support for the shared media capabilities.<br>> > <br>> > Just fyi, work on moap might be slow in the next week since I'm on holiday. It should pick up again after that.<br>> > <br>> > -- <br>> > Justin Clark-Casey (justincc)<br>> > http://justincc.org<br>> > http://twitter.com/justincc<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Message: 2<br>> > Date: Mon, 05 Jul 2010 01:28:30 +0100<br>> > From: Justin Clark-Casey <jjustincc@gmail.com><br>> > To: opensim-users@lists.berlios.de<br>> > Cc: opensim-dev@lists.berlios.de<br>> > Subject: Re: [Opensim-dev] [Opensim-users] OpenSim Roadmap<br>> > Message-ID: <4C31272E.6030706@googlemail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>> > <br>> > On 03/07/10 12:07, Clive Gould wrote:<br>> > > Hi<br>> > ><br>> > > We're presenting the results of Bromley Colleges OpenSim Project at<br>> > > the Future Learningscapes: a 21st Century Challenge conference at<br>> > > Greenwich University (UK) next Wednesday (7th July).<br>> > ><br>> > > Just in case we are asked, can anyone explain OpenSim's roadmap? Why<br>> > > is it still in Alpha and what are the criteria for it getting into<br>> > > Beta and eventually version 1.0?<br>> > <br>> > We haven't had a formal roadmap for quite a while. I think partly this is because of unpredictability about what's <br>> > going to happen with virtual environments, partly because the project is still very young without surplus developers to <br>> > spend time drawing them up :) and partly because the project isn't controlled by a single organization or person that <br>> > could impose such a thing.<br>> > <br>> > However, I'll hazard a personal guess that in the medium-term future we'll see media on a prim and general compatibility <br>> > with version 2 browsers, continued development of hypergrid, more code modularization, mesh support, continued <br>> > improvements in base performance and reliability and scene object refactoring to enable features such as multi-level <br>> > linking. Some of this will be driven by viewer development. And ultimately, everything is driven by user and developer <br>> > requirements, desires and effort/money expenditure :)<br>> > <br>> > I would say that OpenSim is still considered alpha for various reasons, including but not limited to<br>> > <br>> > 1) Current instability in core OpenSim itself.<br>> > 2) Instability in supporting platforms (e.g. mono appears to have issues with high load). This is particularly obvious <br>> > on relatively high-use public grids such as OSGrid.<br>> > 3) Current instability in some features (e.g. setting multiple textures is hit and miss).<br>> > 4) Inconsistency in user-facing interfaces (e.g. help on the console is very unstructured).<br>> > 5) Inconsistency and immaturity of module facilities.<br>> > 6) The prospect of future changes in some fundamental structures (e.g. scene object refactoring).<br>> > 7) Reasonably expected features missing (e.g. no coalesced objects).<br>> > 8) Bad legacy communications interfaces (e.g. the 'wire' protocol for inventory service communication is low quality <br>> > and inconsistent).<br>> > <br>> > This probably sounds rather pessimistic but I think that we've come an awful long way and it's far more valuable early <br>> > on to have rough. working code than spend much time on up-front planning. But I also believe that we couldn't <br>> > justifiably move to beta without addressing a reasonable number of these issues.<br>> > <br>> > Good luck with the conference! Hope you make a few OpenSim converts :)<br>> > <br>> > Regards,<br>> > <br>> > -- <br>> > Justin Clark-Casey (justincc)<br>> > http://justincc.org<br>> > http://twitter.com/justincc<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Message: 3<br>> > Date: Mon, 05 Jul 2010 01:28:39 +0100<br>> > From: Justin Clark-Casey <jjustincc@gmail.com><br>> > To: opensim-dev@lists.berlios.de<br>> > Subject: [Opensim-dev] JSON or XML for serialization in the OpenSim<br>> > database?<br>> > Message-ID: <4C312737.7010103@googlemail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>> > <br>> > Hi folks,<br>> > <br>> > As part of the media-on-a-prim implementation, I'm serializing the parameters for a media texture to the database. This <br>> > seems better than creating new database fields or even a whole new table for these parameters, both because there are <br>> > lots of them (url, scaling, controls, whitelist, etc.) and because different future virtual environments may want to <br>> > store different things.<br>> > <br>> > I'm going to serialize them as an OSDArray or MediaEntrys using the libopenmetaverse library. However, the question <br>> > then becomes whether to use the JSON representation or the XML representation.<br>> > <br>> > I tend to prefer XML for storage representations. I believe that it's somewhat more human readable and that there is <br>> > better tool support for manipulating it. However, I know other people would prefer storage in JSON and I accept that <br>> > serialization/deserialization there may be slightly faster.<br>> > <br>> > The only other example of serialization that I know of in OpenSim currently is that of SceneObjectGroups into inventory, <br>> > which encompasses object properties, object inventory properties and script state. This is done in XML and media <br>> > entries would become part of that serialization.<br>> > <br>> > If there's a majority preference for JSON I don't mind using that instead, though I would want a justification for going <br>> > this route rather than XML. If there's no real argument then I will go with XML.<br>> > <br>> > Also, I believe that we should try and be consistent, so picking one or the other now should make it more likely that <br>> > the same approach would be used for the next serialization case.<br>> > <br>> > Regards,<br>> > <br>> > -- <br>> > Justin Clark-Casey (justincc)<br>> > http://justincc.org<br>> > http://twitter.com/justincc<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Message: 4<br>> > Date: Sun, 4 Jul 2010 20:49:54 -0400<br>> > From: Marc Adored <marc@inworlddesigns.com><br>> > To: opensim-dev@lists.berlios.de<br>> > Subject: [Opensim-dev] compiling viewer-external with ubuntu 64bit<br>> > Message-ID:<br>> > <AANLkTikVu2ASPx9g972vn8U15UsEeTMZgk5EdT7T5G6o@mail.gmail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1<br>> > <br>> > I was wondering if anybody had any success compiling snowglobe on<br>> > ubuntu and if they have what steps they took to prepare their system<br>> > for it. I have installed everything under the sun and my /usr/include<br>> > folder is a mess and I still can't get it to compile in 64bit or<br>> > 32bit.<br>> > <br>> > ./develop.py -m64 -t Release<br>> > Gives me no errors until I do<br>> > <br>> > ./develop.py -m64 -t Release build then it gets to<br>> > <br>> > -- snip --<br>> > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/metaproperty.o<br>> > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/reflective.o<br>> > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/timing.o<br>> > [ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/u64.o<br>> > Linking CXX shared library libllcommon.so<br>> > /usr/bin/ld: cannot find -lbreakpad_client<br>> > collect2: ld returned 1 exit status<br>> > make[2]: *** [llcommon/libllcommon.so] Error 1<br>> > make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2<br>> > make: *** [all] Error 2<br>> > <br>> > <br>> > and it fails. The output above is from me going into<br>> > viewer-linux-x86_64-release and compiling with make to get the<br>> > individual error because ./develop.py doesn't provide it. When I build<br>> > with<br>> > <br>> > ./develop.py -m32 -t Release<br>> > <br>> > -- snip --<br>> > -- Version of viewer is 2.1.0.206484<br>> > -- Configuring done<br>> > CMake Warning at newview/CMakeLists.txt:1393 (add_executable):<br>> > Cannot generate a safe linker search path for target secondlife-bin because<br>> > files in some directories may conflict with libraries in implicit<br>> > directories:<br>> > <br>> > link library [libGLU.so] in /usr/lib may be hidden by files in:<br>> > /media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client<br>> > <br>> > Some of these libraries may not be found correctly.<br>> > <br>> > <br>> > CMake Warning at integration_tests/llui_libtest/CMakeLists.txt:53<br>> > (add_executable):<br>> > Cannot generate a safe linker search path for target llui_libtest because<br>> > files in some directories may conflict with libraries in implicit<br>> > directories:<br>> > <br>> > link library [libGLU.so] in /usr/lib may be hidden by files in:<br>> > /media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client<br>> > <br>> > Some of these libraries may not be found correctly.<br>> > <br>> > <br>> > -- Generating done<br>> > -- Build files have been written to:<br>> > /media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-i686-release<br>> > <br>> > <br>> > Which I assume is not good but it generated everything fine so I continue with<br>> > <br>> > ./develop.py -m32 -t Release build<br>> > <br>> > and get:<br>> > <br>> > <br>> > [ 0%] Built target cmake<br>> > [ 1%] Built target llaudio<br>> > [ 1%] Built target llcommon_tests<br>> > [ 4%] Built target stage_third_party_libs<br>> > Linking CXX shared library libllcommon.so<br>> > /usr/bin/ld: skipping incompatible<br>> > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for<br>> > -lstdc++<br>> > /usr/bin/ld: skipping incompatible<br>> > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for<br>> > -lstdc++<br>> > /usr/bin/ld: skipping incompatible<br>> > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for<br>> > -lstdc++<br>> > /usr/bin/ld: skipping incompatible<br>> > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for<br>> > -lstdc++<br>> > /usr/bin/ld: skipping incompatible<br>> > /usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../libstdc++.so when<br>> > searching for -lstdc++<br>> > /usr/bin/ld: skipping incompatible /usr/lib/libstdc++.so when<br>> > searching for -lstdc++<br>> > /usr/bin/ld: cannot find -lstdc++<br>> > collect2: ld returned 1 exit status<br>> > make[2]: *** [llcommon/libllcommon.so] Error 1<br>> > make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2<br>> > make: *** [all] Error 2<br>> > <br>> > This is also after going into viewer-linux-i686-release and compiling<br>> > with make to see what the actual error was.<br>> > <br>> > If anyone can help that would be greatly appreciated :) I really would<br>> > like to get a 64bit version compiled so I have my gstreamer back. I<br>> > will note that I can successfully compile the code previous to the 2.0<br>> > viewer code and emerald viewer code.<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Message: 5<br>> > Date: Sun, 4 Jul 2010 20:52:16 -0400<br>> > From: Marc Adored <marc@inworlddesigns.com><br>> > To: opensim-dev@lists.berlios.de<br>> > Subject: Re: [Opensim-dev] compiling viewer-external with ubuntu 64bit<br>> > Message-ID:<br>> > <AANLkTim7jfT3FGwFo5xq0pfe4lPdE-EoIEGsKcOF6V6_@mail.gmail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1<br>> > <br>> > I am really sorry guys posted to wrong list please forgive me<br>> > <br>> > On Sun, Jul 4, 2010 at 8:49 PM, Marc Adored <marc@inworlddesigns.com> wrote:<br>> > > I was wondering if anybody had any success compiling snowglobe on<br>> > > ubuntu and if they have what steps they took to prepare their system<br>> > > for it. I have installed everything under the sun and my /usr/include<br>> > > folder is a mess and I still can't get it to compile in 64bit or<br>> > > 32bit.<br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > Message: 6<br>> > Date: Mon, 5 Jul 2010 11:01:20 +0200<br>> > From: Impalah Shenzhou <impalah@gmail.com><br>> > To: opensim-dev@lists.berlios.de<br>> > Subject: Re: [Opensim-dev] JSON or XML for serialization in the<br>> > OpenSim database?<br>> > Message-ID:<br>> > <AANLkTikJufDdnJOxSyX4Bozj4uxU_vCQBtKg1GglUbEn@mail.gmail.com><br>> > Content-Type: text/plain; charset=ISO-8859-1<br>> > <br>> > Hi:<br>> > <br>> > Correct me if I'm wrong but I think that JSON.NET most famous<br>> > serializer/deserializer (http://json.codeplex.com/) works like<br>> > standard .NET XML serializer...<br>> > <br>> > The advantage of using JSON is less storing space and some thing like<br>> > "direct connection" with Javascript. If the first is not a problem and<br>> > you won't publish this kind of information to an external web<br>> > service... well, XML serializer is part of .NET core, and JSON<br>> > serializer is part of a codeplex project... one of them could be<br>> > discontinued some day.<br>> > <br>> > Personally I can't find any advantage on using JSON here except for<br>> > saving disk space and so on.<br>> > <br>> > This is my opinion, I have others if you don't like it :-)<br>> > <br>> > <br>> > Impalah<br>> > <br>> > <br>> > 2010/7/5, Justin Clark-Casey <jjustincc@gmail.com>:<br>> > > Hi folks,<br>> > ><br>> > > As part of the media-on-a-prim implementation, I'm serializing the<br>> > > parameters for a media texture to the database. This<br>> > > seems better than creating new database fields or even a whole new table for<br>> > > these parameters, both because there are<br>> > > lots of them (url, scaling, controls, whitelist, etc.) and because different<br>> > > future virtual environments may want to<br>> > > store different things.<br>> > ><br>> > > I'm going to serialize them as an OSDArray or MediaEntrys using the<br>> > > libopenmetaverse library. However, the question<br>> > > then becomes whether to use the JSON representation or the XML<br>> > > representation.<br>> > ><br>> > > I tend to prefer XML for storage representations. I believe that it's<br>> > > somewhat more human readable and that there is<br>> > > better tool support for manipulating it. However, I know other people would<br>> > > prefer storage in JSON and I accept that<br>> > > serialization/deserialization there may be slightly faster.<br>> > ><br>> > > The only other example of serialization that I know of in OpenSim currently<br>> > > is that of SceneObjectGroups into inventory,<br>> > > which encompasses object properties, object inventory properties and script<br>> > > state. This is done in XML and media<br>> > > entries would become part of that serialization.<br>> > ><br>> > > If there's a majority preference for JSON I don't mind using that instead,<br>> > > though I would want a justification for going<br>> > > this route rather than XML. If there's no real argument then I will go with<br>> > > XML.<br>> > ><br>> > > Also, I believe that we should try and be consistent, so picking one or the<br>> > > other now should make it more likely that<br>> > > the same approach would be used for the next serialization case.<br>> > ><br>> > > Regards,<br>> > ><br>> > > --<br>> > > Justin Clark-Casey (justincc)<br>> > > http://justincc.org<br>> > > http://twitter.com/justincc<br>> > > _______________________________________________<br>> > > Opensim-dev mailing list<br>> > > Opensim-dev@lists.berlios.de<br>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> > ><br>> > <br>> > <br>> > ------------------------------<br>> > <br>> > _______________________________________________<br>> > Opensim-dev mailing list<br>> > Opensim-dev@lists.berlios.de<br>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> > <br>> > <br>> > End of Opensim-dev Digest, Vol 35, Issue 7<br>> > ******************************************<br>> <br>> _________________________________________________________________<br>> Hotmail: Trusted email with Microsoft?s powerful SPAM protection.<br>> https://signup.live.com/signup.aspx?id=60969<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://lists.berlios.de/pipermail/opensim-dev/attachments/20100713/93766a49/attachment.html><br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> End of Opensim-dev Digest, Vol 35, Issue 35<br>> *******************************************<br></div> <br /><hr />Hotmail: Trusted email with powerful SPAM protection. <a href='https://signup.live.com/signup.aspx?id=60969' target='_new'>Sign up now.</a></body>
</html>