Hello, I need help in order to keep my sanity, lol<br>When I try to run any of opensim binaries including the linux download version with mono on Fedora 8 I get the following error.<br><br>------<br><br>** (./OpenSim.exe:4771): WARNING **: The following assembly referenced from /root/Desktop/opensimbin/OpenSim.Framework.Data.SQLite.dll could not be loaded:<br>     Assembly:   System.Data    (assemblyref_index=1)<br>     Version:    2.0.0.0<br>     Public Key: b77a5c561934e089<br>The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/root/Desktop/opensimbin/).<br><br>------<br><br>I ran the non linux download using mono on Fedora and got the same result.<br>I also ran the windows binaries on windows xp using mono and it runs just fine, so it seems I am lacking something on

Fedora, but I am using everything that it said in the readme to run it on linux but it won't run, System.Data.dll is present so I do not see why this is happening. Thanks a bunch! -Nitrus Nori opensim-dev-request@lists.berlios.de wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Send Opensim-dev mailing list submissions to  opensim-dev@lists.berlios.de To subscribe or unsubscribe via the World Wide Web, visit  https://lists.berlios.de/mailman/listinfo/opensim-dev or, via email, send a message with subject or body 'help' to  opensim-dev-request@lists.berlios.de You can reach the person managing the list at  opensim-dev-owner@lists.berlios.de When replying, please edit your Subject line so it is more specific than "Re: Contents of Opensim-dev digest..." Today's Topics:    1. Re: Where should we put GetUserAppearance ?

 (Sean Dague)<br>   2. Re: what to use for serializing structures? LLSD?<br>      XmlSerializer? JSON? (Justin Clark-Casey)<br>   3. Re: what to use for serializing structures? LLSD?<br>      XmlSerializer? JSON? (Kyle Hamilton)<br>   4. Re: what to use for serializing structures? LLSD?<br>      XmlSerializer? JSON? (Mo Hax)<br>   5. Re: what to use for serializing structures? LLSD?<br>      XmlSerializer? JSON? (Mo Hax)<br>   6. Re: what to use for serializing structures? LLSD?<br>      XmlSerializer? JSON? (Sean Dague)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 14 May 2008 08:50:25 -0400<br>From: Sean Dague <sean@dague.net><br>Subject: Re: [Opensim-dev] Where should we put GetUserAppearance ?<br>To: opensim-dev@lists.berlios.de<br>Message-ID: <20080514125025.GY8134@dague.net><br>Content-Type: text/plain; charset="us-ascii"<br><br>On Wed, May 14, 2008 at 03:48:08PM +0900, liu xiaolu wrote:<br>>

 Hi, everyone,<br>> I am planing to implement "AssetPortability" in OpenSim,<br>> The basic idea is to let RegionServer get assets from a<br>> dynamic(user specified) AssetServerURL.<br>> <br>> Very thankful for someone added "asseturl" and "inventoryurl"<br>> to the userprofile structure and the "Users" table.<br>> (though I do not know exactly what it was he did)<br>> <br>> Recently, I found there is a stub "GetUserAppearance" in "IUserService".<br>> This is a little different from what I am thinking, so here I would like to<br>> share my plan for the "appearance portability" and have a discussion<br>> with you.<br>> <br>> # Preparation<br>> 1. User stores "wearables" in "inventoryserver"<br>> 2. User stores actual "assetdata" in "assetserver"<br>> 3. User tells its "asset/inventory url" to "userserver"<br>> (by user registration or someway like openid)<br>> <br>> # Login<br>> At

 http://openugai.sourceforge.net/?page=openasset_proposal<br>> there are 2 possible patterns,<br>> "Implemetation 1" is following current opensim - "GetUserAppearance" in<br>> "UserServive".<br>> "Implemetation 2" is my proposal.<br>> <br>> * Implemetation 1<br>> 1. "UserServer" acts as a agent, when "GetUserAppearance" called,<br>> 2. "UserServer" gets "wearables" from "inventoryserver"<br>> 3. "UserServer" gets "assetdata" foreach "wearables" UUID.<br>> 4. "UserServer" returns appearance to RegionServer(OGS1UserServices)<br><br>Actually, you have this flow wrong.<br><br> 1. Client -> Sim -> User Server (Get My Appearance)<br> 2. User Server -> Sim -> Client (Appearance Packet - lots of UUIDs)<br> 3. Client -> Sim -> Asset Server (foreach wearable get asset)<br> 4. Client -> Sim -> Inventory Server (foreach wearable get inventory)<br><br>If you look a little deeper on the GetUserAppearance data structures<br>you'll see

 that only UUIDs are flying around.  There will probably be a<br>caching of visual params as well, as it will make your ruth time when<br>you first log in smaller.<br><br>> * Implemetation 2<br>> "GetUserAppearance" is not in "UserServer", it should be a module or<br>> something<br>> independent. There is<br>> * "OGS1InventoryServices" incharge of communicating with "InventoryServer".<br>> * "AssetCache" gets "assetdata" from "AssetServer".<br>> I think we can use the 2 existing components to "GetUserAppearance".<br>> <br>> Why I prefer "Implementation 2" ?<br>> 1. Just as UserServer does not provide "Inventory" information, UesrServer<br>> also should NOT<br>> provide appearance information.<br>> (UserServer should be concentrated on providing basic user information and<br>> the authentication.)<br>> 2. If UserServer have to fetch Complete "Appearance", UserServer must know<br>> about AssetServerUrl,<br>> and something

 like "AssetCache" must be implemented inside UserServer. This<br>> makes UserServer<br>> become less indenpendent.<br><br>That's actually not true.  With the user server storing asset and<br>inventory ids, the client is sent a wearables packet, which is just a<br>bunch of UUIDs.  The client then goes and fetches the assets from the<br>asset servers.<br><br>> 3. "Appearance" can be thought as "a special inventory folder called<br>> 'wearables' ".<br>> (InventoryServer is born to do such things)<br><br>I think that mapping "special cases" onto existing services is trouble<br>waiting to happen.<br><br>    -Sean<br><br>-- <br>__________________________________________________________________<br><br>Sean Dague                                       Mid-Hudson Valley<br>sean at dague dot net                            Linux Users Group<br>http://dague.net                                 http://mhvlug.org<br><br>There is no silver bullet.  Plus, werewolves make

 better neighbors<br>than zombies, and they tend to keep the vampire population down.<br>__________________________________________________________________<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: not available<br>Type: application/pgp-signature<br>Size: 189 bytes<br>Desc: Digital signature<br>Url : https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/2e51c84f/attachment-0001.pgp <br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 14 May 2008 13:55:58 +0100<br>From: Justin Clark-Casey <jjustincc@googlemail.com><br>Subject: Re: [Opensim-dev] what to use for serializing structures?<br> LLSD? XmlSerializer? JSON?<br>To: opensim-dev@lists.berlios.de<br>Message-ID: <482AE15E.5020302@googlemail.com><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Dr Scofield wrote:<br>> Stefan Andersson wrote:<br>>> Ok, next time, I'll half the dose of that cough

 syrup.<br>>>  <br>>> Aaanyway : I still think it's a REALLY bad idea to put forward as a <br>>> 'standard region API' something that is more <br>>> application-and-environment specific (JSON) when there is something <br>>> that is less application-and-environment specific (XML)<br>> oops...this is not a standard region API, this is supposed to be a <br>> control API to allow us to control region specific information of an <br>> OpenSim instance.<br>>> Is there a concrete win with Json over Xml that I'm missing?<br>> i'd say, easy to parse from AJAX side, less verbose, doesn't require <br>> knowledge of the class definition to make sense of it (well, at least to <br>> some extent).<br><br> From what I've read of JSON, I don't believe it's tied to any specific <br>language - to some extent it just happens to be directly evaluatable in <br>Javascript since that was from where it originated.<br><br>However, I do personally

 prefer XML - there are just more tools and <br>libraries out there for it and it's more familiar.  I'm not sure the <br>possible advantages of JSON (e.g. less verbosity, though I'm not sure <br>that's an issue here) outweigh that.<br><br>Oh, and regarding LLSD - yes, let's confine that to linden interop and <br>not use it as our core REST format.<br><br>>>  <br>>> And, it would be great if the api was formulated as a set of abstract <br>>> classes, interfaces and event hooks, so however you decide to <br>>> implement the protocol layer, somebody else could implement it <br>>> differently. (SOAP, anybody?)<br>> hmm...not sure whether i really want to add lots and lots of code around <br>> a simple control API.<br>> <br>> we've got a specific need in mind: control an OpenSim instance via REST <br>> instead of via console. REST appears to be resource/state centric, <br>> XmlRpc/SOAP/et al seems to be more object--method

 oriented.<br>> <br><br>I would agree.  Let's have a nice simple REST interface (alongside the <br>existing XMLRPC for now).  If we need to elaborate this can happen later <br>on...<br><br>-- <br>justincc<br>Justin Clark-Casey<br>http://justincc.wordpress.com<br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 14 May 2008 06:40:32 -0700<br>From: "Kyle Hamilton" <aerowolf@gmail.com><br>Subject: Re: [Opensim-dev] what to use for serializing structures?<br> LLSD? XmlSerializer? JSON?<br>To: opensim-dev@lists.berlios.de<br>Message-ID:<br> <6b9359640805140640x729954d3p71ca4e614735cf08@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>XML is not "lightweight".  It takes a LOT to be able to use it<br>properly, and this reduces its utility and increases the barrier to<br>entry.<br><br>(Yes, it's possible to prove of XML that 'it matches the schema'<br>[presuming the schema is defined], but even then I tend to think that<br>values

 usually aren't checked for sanity before use.)<br><br>JSON has the advantage of being easy to parse, decreasing network<br>protocol overhead, having many implementations, being directly<br>mappable to C# primitives and classes without expensive overhead, not<br>requiring a predefined schema, and allowing for more useful data<br>handling...  as well as being much more easily read by people who<br>understand C or C# without having to worry about learning some kind of<br>markup that has begun to rival SGML for sheer attempted generality<br>(and thus complexity).<br><br>To get a grasp of what it is I'm talking about, look at the number of<br>pages in the XML standard.  Then look at the number of pages in the<br>JSON description (RFC 4627).  And then look at http://json.org/ to<br>figure out how many implementations of JSON parsing there are for C#.<br>(not to mention how few diagrams are actually required to describe the<br>language.)<br><br>I believe that XML, while useful in

 many contexts, suffers from the<br>same problems that the Electronic Data Interchange standard has (such<br>as "the schema must be known at both ends").  As well, It is far too<br>formalized, the tag lengths are far too arbitrary, and the sheer<br>number of times those tags must be duplicated is insane (and, while it<br>makes adaptive-dictionary compression work really well, that's the<br>kind of redundancy that is really inappopriate for any kind of network<br>protocol).<br><br>I'm forced to remind everyone of something that they've all seemed to<br>forget: increasing the amount of data to be transferred increases the<br>number of packets that must be transmitted.  Increasing the number of<br>packets transmitted increases the amount of work that the network must<br>do.  Increasing the amount of data to be transferred also increases<br>memory usage on the client and server -- as well as the amount of<br>memory that must be used on each router and gateway in between. 

 (Why<br>can't the designers of new systems be nice to the network operators<br>for once, and not force them to non-trivial expansions of their<br>network capacity?)<br><br>JSON is MUCH easier to parse than XML.  While, yes, our systems have<br>more raw processing power than ever before in our history, our systems<br>have been getting slower because everyone has been much more lax about<br>"we have lots of memory and processing power to play with".  This<br>includes the W3C.  This also includes the people who use the standards<br>promulgated by them.  This includes the people who have written the<br>parsers which have been created for use with XML.<br><br>I would vote that we should reduce the processing power required, so<br>that more simultaneous connections can be dealt with.  I would vote<br>that we should reduce the protocol overhead, so that it is easier to<br>process and transfer.  I would vote that we keep in mind that just<br>because there's more processing power

 to play with doesn't mean that<br>we should extend the sandbox beyond the very minimum necessary to make<br>it easy to play within.<br><br>And above all, I would vote that it be made a guiding principle in the<br>design to minimize resource impact -- both data storage (hard<br>disk/database) and data transmission (network).<br><br>-Kyle H<br><br>On Wed, May 14, 2008 at 5:55 AM, Justin Clark-Casey<br><jjustincc@googlemail.com> wrote:<br>> Dr Scofield wrote:<br>>  > Stefan Andersson wrote:<br>>  >> Ok, next time, I'll half the dose of that cough syrup.<br>>  >><br>>  >> Aaanyway : I still think it's a REALLY bad idea to put forward as a<br>>  >> 'standard region API' something that is more<br>>  >> application-and-environment specific (JSON) when there is something<br>>  >> that is less application-and-environment specific (XML)<br>>  > oops...this is not a standard region API, this is supposed to be

 a<br>>  > control API to allow us to control region specific information of an<br>>  > OpenSim instance.<br>>  >> Is there a concrete win with Json over Xml that I'm missing?<br>>  > i'd say, easy to parse from AJAX side, less verbose, doesn't require<br>>  > knowledge of the class definition to make sense of it (well, at least to<br>>  > some extent).<br>><br>>   From what I've read of JSON, I don't believe it's tied to any specific<br>>  language - to some extent it just happens to be directly evaluatable in<br>>  Javascript since that was from where it originated.<br>><br>>  However, I do personally prefer XML - there are just more tools and<br>>  libraries out there for it and it's more familiar.  I'm not sure the<br>>  possible advantages of JSON (e.g. less verbosity, though I'm not sure<br>>  that's an issue here) outweigh that.<br>><br>>  Oh, and regarding LLSD - yes, let's confine that to

 linden interop and<br>>  not use it as our core REST format.<br>><br>><br>>  >><br>>  >> And, it would be great if the api was formulated as a set of abstract<br>>  >> classes, interfaces and event hooks, so however you decide to<br>>  >> implement the protocol layer, somebody else could implement it<br>>  >> differently. (SOAP, anybody?)<br>>  > hmm...not sure whether i really want to add lots and lots of code around<br>>  > a simple control API.<br>>  ><br>>  > we've got a specific need in mind: control an OpenSim instance via REST<br>>  > instead of via console. REST appears to be resource/state centric,<br>>  > XmlRpc/SOAP/et al seems to be more object--method oriented.<br>>  ><br>><br>>  I would agree.  Let's have a nice simple REST interface (alongside the<br>>  existing XMLRPC for now).  If we need to elaborate this can happen later<br>>  on...<br>><br>>

  --<br>>  justincc<br>>  Justin Clark-Casey<br>>  http://justincc.wordpress.com<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><br>------------------------------<br><br>Message: 4<br>Date: Wed, 14 May 2008 09:46:17 -0400<br>From: "Mo Hax" <imohax@gmail.com><br>Subject: Re: [Opensim-dev] what to use for serializing structures?<br> LLSD? XmlSerializer? JSON?<br>To: opensim-dev@lists.berlios.de<br>Message-ID:<br> <a5f6fe50805140646g26083eb4i78cf79911fac6b2e@mail.gmail.com><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Thanks for this thread, Dirk,<br><br><br>For those who might actually want to read up on the differences before<br>weighing in, here are some URLs:<br><br>   - http://www.json.org<br>   - http://wiki.secondlife.com/wiki/LLSD<br>   - http://asn1.elibel.tm.fr<br><br>Hate

 to be the wet blanket, and I am still very early to the party, but<br>isn't the burden of 'proof' on JSON to show that adding yet another tech to<br>the OpenSim code base is worth it, no matter how simple and cool it is?<br><br>What is it going to be used for? Who's the customer? People coding<br>administrative front ends? Does this have any chance of growing into<br>something more, like a way to query or add serialized assets?<br><br>JSON seems obvious if this is just for administrative front end mashups.<br>Maybe we limit the scope to that and make it JSON.<br><br>LLSD would be my pick for asset serialization and such since it is more<br>largely compatible with LL and the working group and includes three forms,<br>xml, binary, and 'human readable', which I think is the one you are<br>comparing JSON with.<br><br>I suppose nothing wrong with having right tool for the job, and little<br>mashes up better than JSON. But overall I prefer using what we have whenever<br>we can

 (spoken like a true newbie reading hundreds of lines a day to catch<br>up).<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/8427cf92/attachment-0001.html <br><br>------------------------------<br><br>Message: 5<br>Date: Wed, 14 May 2008 09:50:31 -0400<br>From: "Mo Hax" <imohax@gmail.com><br>Subject: Re: [Opensim-dev] what to use for serializing structures?<br> LLSD? XmlSerializer? JSON?<br>To: opensim-dev@lists.berlios.de<br>Message-ID:<br> <a5f6fe50805140650w1f21e038m339a9ca4f04792b3@mail.gmail.com><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>On Wed, May 14, 2008 at 9:40 AM, Kyle Hamilton <aerowolf@gmail.com> wrote:<br><br><br>> I'm forced to remind everyone of something that they've all seemed to<br>> forget: increasing the amount of data to be transferred increases the<br>> number of packets that must be transmitted.  Increasing the number

 of<br>> packets transmitted increases the amount of work that the network must<br>> do.  Increasing the amount of data to be transferred also increases<br>> memory usage on the client and server -- as well as the amount of<br>> memory that must be used on each router and gateway in between.  (Why<br>> can't the designers of new systems be nice to the network operators<br>> for once, and not force them to non-trivial expansions of their<br>> network capacity?)<br><br><br>Which is why LLSD has the tersest possible binary format and a terser than<br>XML 'human readable format'. Again, I keep coming back to the 'why add<br>more?' and 'what is this going to specifically be used for?' question. That<br>would shape the discussion and decision in my book.<br><br>Respectfully,<br><br>Mo<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:

 https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/3ced2a66/attachment-0001.html <br><br>------------------------------<br><br>Message: 6<br>Date: Wed, 14 May 2008 09:57:40 -0400<br>From: Sean Dague <sean@dague.net><br>Subject: Re: [Opensim-dev] what to use for serializing structures?<br> LLSD? XmlSerializer? JSON?<br>To: opensim-dev@lists.berlios.de<br>Message-ID: <20080514135740.GZ8134@dague.net><br>Content-Type: text/plain; charset="us-ascii"<br><br>On Wed, May 14, 2008 at 01:55:58PM +0100, Justin Clark-Casey wrote:<br>> Dr Scofield wrote:<br>> > Stefan Andersson wrote:<br>> >> Ok, next time, I'll half the dose of that cough syrup.<br>> >>  <br>> >> Aaanyway : I still think it's a REALLY bad idea to put forward as a <br>> >> 'standard region API' something that is more <br>> >> application-and-environment specific (JSON) when there is something <br>> >> that is less

 application-and-environment specific (XML)<br>> > oops...this is not a standard region API, this is supposed to be a <br>> > control API to allow us to control region specific information of an <br>> > OpenSim instance.<br>> >> Is there a concrete win with Json over Xml that I'm missing?<br>> > i'd say, easy to parse from AJAX side, less verbose, doesn't require <br>> > knowledge of the class definition to make sense of it (well, at least to <br>> > some extent).<br>> <br>>  From what I've read of JSON, I don't believe it's tied to any specific <br>> language - to some extent it just happens to be directly evaluatable in <br>> Javascript since that was from where it originated.<br>> <br>> However, I do personally prefer XML - there are just more tools and <br>> libraries out there for it and it's more familiar.  I'm not sure the <br>> possible advantages of JSON (e.g. less verbosity, though I'm not sure

 <br>> that's an issue here) outweigh that.<br><br>While I personally prefer the readability of JSON, I think for the<br>OpenSim project XML makes more sense.  Our cannonical serialization<br>models will end up in XML, and that will be our standard interchange<br>format.  All languages do pretty well with XML at this point. :)  (it is<br>the X in AJAX).<br><br>That being said, by definition, REST base approaches are supposed to<br>support the Content-Type header.  As long as that serialization<br>seperation is handled correctly, we could build JSON/Text/Image whatever<br>formats down the road.<br><br>> Oh, and regarding LLSD - yes, let's confine that to linden interop and <br>> not use it as our core REST format.<br><br>LLSD is super extra verbose for a wire protocol, so +1.<br><br>     -Sean<br><br>-- <br>__________________________________________________________________<br><br>Sean Dague                                       Mid-Hudson Valley<br>sean at dague dot

 net                            Linux Users Group<br>http://dague.net                                 http://mhvlug.org<br><br>There is no silver bullet.  Plus, werewolves make better neighbors<br>than zombies, and they tend to keep the vampire population down.<br>__________________________________________________________________<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br><br>=== message truncated ===</sean@dague.net></aerowolf@gmail.com></a5f6fe50805140650w1f21e038m339a9ca4f04792b3@mail.gmail.com></imohax@gmail.com></a5f6fe50805140646g26083eb4i78cf79911fac6b2e@mail.gmail.com></imohax@gmail.com></jjustincc@googlemail.com></aerowolf@gmail.com></jjustincc@googlemail.com></sean@dague.net></blockquote><br><p> 