[Opensim-dev] Opensim-dev Digest, Vol 9, Issue 13
Ryan Farnham
nitruswolfy at yahoo.com
Wed May 14 23:32:29 UTC 2008
Hello, I need help in order to keep my sanity, lol
When I try to run any of opensim binaries including the linux download version with mono on Fedora 8 I get the following error.
------
** (./OpenSim.exe:4771): WARNING **: The following assembly referenced from /root/Desktop/opensimbin/OpenSim.Framework.Data.SQLite.dll could not be loaded:
Assembly: System.Data (assemblyref_index=1)
Version: 2.0.0.0
Public Key: b77a5c561934e089
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/).
------
I ran the non linux download using mono on Fedora and got the same result.
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 at lists.berlios.de wrote: Send Opensim-dev mailing list submissions to
opensim-dev at 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 at lists.berlios.de
You can reach the person managing the list at
opensim-dev-owner at 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)
2. Re: what to use for serializing structures? LLSD?
XmlSerializer? JSON? (Justin Clark-Casey)
3. Re: what to use for serializing structures? LLSD?
XmlSerializer? JSON? (Kyle Hamilton)
4. Re: what to use for serializing structures? LLSD?
XmlSerializer? JSON? (Mo Hax)
5. Re: what to use for serializing structures? LLSD?
XmlSerializer? JSON? (Mo Hax)
6. Re: what to use for serializing structures? LLSD?
XmlSerializer? JSON? (Sean Dague)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 May 2008 08:50:25 -0400
From: Sean Dague
Subject: Re: [Opensim-dev] Where should we put GetUserAppearance ?
To: opensim-dev at lists.berlios.de
Message-ID: <20080514125025.GY8134 at dague.net>
Content-Type: text/plain; charset="us-ascii"
On Wed, May 14, 2008 at 03:48:08PM +0900, liu xiaolu wrote:
> Hi, everyone,
> I am planing to implement "AssetPortability" in OpenSim,
> The basic idea is to let RegionServer get assets from a
> dynamic(user specified) AssetServerURL.
>
> Very thankful for someone added "asseturl" and "inventoryurl"
> to the userprofile structure and the "Users" table.
> (though I do not know exactly what it was he did)
>
> Recently, I found there is a stub "GetUserAppearance" in "IUserService".
> This is a little different from what I am thinking, so here I would like to
> share my plan for the "appearance portability" and have a discussion
> with you.
>
> # Preparation
> 1. User stores "wearables" in "inventoryserver"
> 2. User stores actual "assetdata" in "assetserver"
> 3. User tells its "asset/inventory url" to "userserver"
> (by user registration or someway like openid)
>
> # Login
> At http://openugai.sourceforge.net/?page=openasset_proposal
> there are 2 possible patterns,
> "Implemetation 1" is following current opensim - "GetUserAppearance" in
> "UserServive".
> "Implemetation 2" is my proposal.
>
> * Implemetation 1
> 1. "UserServer" acts as a agent, when "GetUserAppearance" called,
> 2. "UserServer" gets "wearables" from "inventoryserver"
> 3. "UserServer" gets "assetdata" foreach "wearables" UUID.
> 4. "UserServer" returns appearance to RegionServer(OGS1UserServices)
Actually, you have this flow wrong.
1. Client -> Sim -> User Server (Get My Appearance)
2. User Server -> Sim -> Client (Appearance Packet - lots of UUIDs)
3. Client -> Sim -> Asset Server (foreach wearable get asset)
4. Client -> Sim -> Inventory Server (foreach wearable get inventory)
If you look a little deeper on the GetUserAppearance data structures
you'll see that only UUIDs are flying around. There will probably be a
caching of visual params as well, as it will make your ruth time when
you first log in smaller.
> * Implemetation 2
> "GetUserAppearance" is not in "UserServer", it should be a module or
> something
> independent. There is
> * "OGS1InventoryServices" incharge of communicating with "InventoryServer".
> * "AssetCache" gets "assetdata" from "AssetServer".
> I think we can use the 2 existing components to "GetUserAppearance".
>
> Why I prefer "Implementation 2" ?
> 1. Just as UserServer does not provide "Inventory" information, UesrServer
> also should NOT
> provide appearance information.
> (UserServer should be concentrated on providing basic user information and
> the authentication.)
> 2. If UserServer have to fetch Complete "Appearance", UserServer must know
> about AssetServerUrl,
> and something like "AssetCache" must be implemented inside UserServer. This
> makes UserServer
> become less indenpendent.
That's actually not true. With the user server storing asset and
inventory ids, the client is sent a wearables packet, which is just a
bunch of UUIDs. The client then goes and fetches the assets from the
asset servers.
> 3. "Appearance" can be thought as "a special inventory folder called
> 'wearables' ".
> (InventoryServer is born to do such things)
I think that mapping "special cases" onto existing services is trouble
waiting to happen.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/2e51c84f/attachment-0001.pgp
------------------------------
Message: 2
Date: Wed, 14 May 2008 13:55:58 +0100
From: Justin Clark-Casey
Subject: Re: [Opensim-dev] what to use for serializing structures?
LLSD? XmlSerializer? JSON?
To: opensim-dev at lists.berlios.de
Message-ID: <482AE15E.5020302 at googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dr Scofield wrote:
> Stefan Andersson wrote:
>> Ok, next time, I'll half the dose of that cough syrup.
>>
>> Aaanyway : I still think it's a REALLY bad idea to put forward as a
>> 'standard region API' something that is more
>> application-and-environment specific (JSON) when there is something
>> that is less application-and-environment specific (XML)
> oops...this is not a standard region API, this is supposed to be a
> control API to allow us to control region specific information of an
> OpenSim instance.
>> Is there a concrete win with Json over Xml that I'm missing?
> i'd say, easy to parse from AJAX side, less verbose, doesn't require
> knowledge of the class definition to make sense of it (well, at least to
> some extent).
From what I've read of JSON, I don't believe it's tied to any specific
language - to some extent it just happens to be directly evaluatable in
Javascript since that was from where it originated.
However, I do personally prefer XML - there are just more tools and
libraries out there for it and it's more familiar. I'm not sure the
possible advantages of JSON (e.g. less verbosity, though I'm not sure
that's an issue here) outweigh that.
Oh, and regarding LLSD - yes, let's confine that to linden interop and
not use it as our core REST format.
>>
>> And, it would be great if the api was formulated as a set of abstract
>> classes, interfaces and event hooks, so however you decide to
>> implement the protocol layer, somebody else could implement it
>> differently. (SOAP, anybody?)
> hmm...not sure whether i really want to add lots and lots of code around
> a simple control API.
>
> we've got a specific need in mind: control an OpenSim instance via REST
> instead of via console. REST appears to be resource/state centric,
> XmlRpc/SOAP/et al seems to be more object--method oriented.
>
I would agree. Let's have a nice simple REST interface (alongside the
existing XMLRPC for now). If we need to elaborate this can happen later
on...
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
------------------------------
Message: 3
Date: Wed, 14 May 2008 06:40:32 -0700
From: "Kyle Hamilton"
Subject: Re: [Opensim-dev] what to use for serializing structures?
LLSD? XmlSerializer? JSON?
To: opensim-dev at lists.berlios.de
Message-ID:
<6b9359640805140640x729954d3p71ca4e614735cf08 at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
XML is not "lightweight". It takes a LOT to be able to use it
properly, and this reduces its utility and increases the barrier to
entry.
(Yes, it's possible to prove of XML that 'it matches the schema'
[presuming the schema is defined], but even then I tend to think that
values usually aren't checked for sanity before use.)
JSON has the advantage of being easy to parse, decreasing network
protocol overhead, having many implementations, being directly
mappable to C# primitives and classes without expensive overhead, not
requiring a predefined schema, and allowing for more useful data
handling... as well as being much more easily read by people who
understand C or C# without having to worry about learning some kind of
markup that has begun to rival SGML for sheer attempted generality
(and thus complexity).
To get a grasp of what it is I'm talking about, look at the number of
pages in the XML standard. Then look at the number of pages in the
JSON description (RFC 4627). And then look at http://json.org/ to
figure out how many implementations of JSON parsing there are for C#.
(not to mention how few diagrams are actually required to describe the
language.)
I believe that XML, while useful in many contexts, suffers from the
same problems that the Electronic Data Interchange standard has (such
as "the schema must be known at both ends"). As well, It is far too
formalized, the tag lengths are far too arbitrary, and the sheer
number of times those tags must be duplicated is insane (and, while it
makes adaptive-dictionary compression work really well, that's the
kind of redundancy that is really inappopriate for any kind of network
protocol).
I'm forced to remind everyone of something that they've all seemed to
forget: increasing the amount of data to be transferred increases the
number of packets that must be transmitted. Increasing the number of
packets transmitted increases the amount of work that the network must
do. Increasing the amount of data to be transferred also increases
memory usage on the client and server -- as well as the amount of
memory that must be used on each router and gateway in between. (Why
can't the designers of new systems be nice to the network operators
for once, and not force them to non-trivial expansions of their
network capacity?)
JSON is MUCH easier to parse than XML. While, yes, our systems have
more raw processing power than ever before in our history, our systems
have been getting slower because everyone has been much more lax about
"we have lots of memory and processing power to play with". This
includes the W3C. This also includes the people who use the standards
promulgated by them. This includes the people who have written the
parsers which have been created for use with XML.
I would vote that we should reduce the processing power required, so
that more simultaneous connections can be dealt with. I would vote
that we should reduce the protocol overhead, so that it is easier to
process and transfer. I would vote that we keep in mind that just
because there's more processing power to play with doesn't mean that
we should extend the sandbox beyond the very minimum necessary to make
it easy to play within.
And above all, I would vote that it be made a guiding principle in the
design to minimize resource impact -- both data storage (hard
disk/database) and data transmission (network).
-Kyle H
On Wed, May 14, 2008 at 5:55 AM, Justin Clark-Casey
wrote:
> Dr Scofield wrote:
> > Stefan Andersson wrote:
> >> Ok, next time, I'll half the dose of that cough syrup.
> >>
> >> Aaanyway : I still think it's a REALLY bad idea to put forward as a
> >> 'standard region API' something that is more
> >> application-and-environment specific (JSON) when there is something
> >> that is less application-and-environment specific (XML)
> > oops...this is not a standard region API, this is supposed to be a
> > control API to allow us to control region specific information of an
> > OpenSim instance.
> >> Is there a concrete win with Json over Xml that I'm missing?
> > i'd say, easy to parse from AJAX side, less verbose, doesn't require
> > knowledge of the class definition to make sense of it (well, at least to
> > some extent).
>
> From what I've read of JSON, I don't believe it's tied to any specific
> language - to some extent it just happens to be directly evaluatable in
> Javascript since that was from where it originated.
>
> However, I do personally prefer XML - there are just more tools and
> libraries out there for it and it's more familiar. I'm not sure the
> possible advantages of JSON (e.g. less verbosity, though I'm not sure
> that's an issue here) outweigh that.
>
> Oh, and regarding LLSD - yes, let's confine that to linden interop and
> not use it as our core REST format.
>
>
> >>
> >> And, it would be great if the api was formulated as a set of abstract
> >> classes, interfaces and event hooks, so however you decide to
> >> implement the protocol layer, somebody else could implement it
> >> differently. (SOAP, anybody?)
> > hmm...not sure whether i really want to add lots and lots of code around
> > a simple control API.
> >
> > we've got a specific need in mind: control an OpenSim instance via REST
> > instead of via console. REST appears to be resource/state centric,
> > XmlRpc/SOAP/et al seems to be more object--method oriented.
> >
>
> I would agree. Let's have a nice simple REST interface (alongside the
> existing XMLRPC for now). If we need to elaborate this can happen later
> on...
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
------------------------------
Message: 4
Date: Wed, 14 May 2008 09:46:17 -0400
From: "Mo Hax"
Subject: Re: [Opensim-dev] what to use for serializing structures?
LLSD? XmlSerializer? JSON?
To: opensim-dev at lists.berlios.de
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Thanks for this thread, Dirk,
For those who might actually want to read up on the differences before
weighing in, here are some URLs:
- http://www.json.org
- http://wiki.secondlife.com/wiki/LLSD
- http://asn1.elibel.tm.fr
Hate to be the wet blanket, and I am still very early to the party, but
isn't the burden of 'proof' on JSON to show that adding yet another tech to
the OpenSim code base is worth it, no matter how simple and cool it is?
What is it going to be used for? Who's the customer? People coding
administrative front ends? Does this have any chance of growing into
something more, like a way to query or add serialized assets?
JSON seems obvious if this is just for administrative front end mashups.
Maybe we limit the scope to that and make it JSON.
LLSD would be my pick for asset serialization and such since it is more
largely compatible with LL and the working group and includes three forms,
xml, binary, and 'human readable', which I think is the one you are
comparing JSON with.
I suppose nothing wrong with having right tool for the job, and little
mashes up better than JSON. But overall I prefer using what we have whenever
we can (spoken like a true newbie reading hundreds of lines a day to catch
up).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/8427cf92/attachment-0001.html
------------------------------
Message: 5
Date: Wed, 14 May 2008 09:50:31 -0400
From: "Mo Hax"
Subject: Re: [Opensim-dev] what to use for serializing structures?
LLSD? XmlSerializer? JSON?
To: opensim-dev at lists.berlios.de
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
On Wed, May 14, 2008 at 9:40 AM, Kyle Hamilton wrote:
> I'm forced to remind everyone of something that they've all seemed to
> forget: increasing the amount of data to be transferred increases the
> number of packets that must be transmitted. Increasing the number of
> packets transmitted increases the amount of work that the network must
> do. Increasing the amount of data to be transferred also increases
> memory usage on the client and server -- as well as the amount of
> memory that must be used on each router and gateway in between. (Why
> can't the designers of new systems be nice to the network operators
> for once, and not force them to non-trivial expansions of their
> network capacity?)
Which is why LLSD has the tersest possible binary format and a terser than
XML 'human readable format'. Again, I keep coming back to the 'why add
more?' and 'what is this going to specifically be used for?' question. That
would shape the discussion and decision in my book.
Respectfully,
Mo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/opensim-dev/attachments/20080514/3ced2a66/attachment-0001.html
------------------------------
Message: 6
Date: Wed, 14 May 2008 09:57:40 -0400
From: Sean Dague
Subject: Re: [Opensim-dev] what to use for serializing structures?
LLSD? XmlSerializer? JSON?
To: opensim-dev at lists.berlios.de
Message-ID: <20080514135740.GZ8134 at dague.net>
Content-Type: text/plain; charset="us-ascii"
On Wed, May 14, 2008 at 01:55:58PM +0100, Justin Clark-Casey wrote:
> Dr Scofield wrote:
> > Stefan Andersson wrote:
> >> Ok, next time, I'll half the dose of that cough syrup.
> >>
> >> Aaanyway : I still think it's a REALLY bad idea to put forward as a
> >> 'standard region API' something that is more
> >> application-and-environment specific (JSON) when there is something
> >> that is less application-and-environment specific (XML)
> > oops...this is not a standard region API, this is supposed to be a
> > control API to allow us to control region specific information of an
> > OpenSim instance.
> >> Is there a concrete win with Json over Xml that I'm missing?
> > i'd say, easy to parse from AJAX side, less verbose, doesn't require
> > knowledge of the class definition to make sense of it (well, at least to
> > some extent).
>
> From what I've read of JSON, I don't believe it's tied to any specific
> language - to some extent it just happens to be directly evaluatable in
> Javascript since that was from where it originated.
>
> However, I do personally prefer XML - there are just more tools and
> libraries out there for it and it's more familiar. I'm not sure the
> possible advantages of JSON (e.g. less verbosity, though I'm not sure
> that's an issue here) outweigh that.
While I personally prefer the readability of JSON, I think for the
OpenSim project XML makes more sense. Our cannonical serialization
models will end up in XML, and that will be our standard interchange
format. All languages do pretty well with XML at this point. :) (it is
the X in AJAX).
That being said, by definition, REST base approaches are supposed to
support the Content-Type header. As long as that serialization
seperation is handled correctly, we could build JSON/Text/Image whatever
formats down the road.
> Oh, and regarding LLSD - yes, let's confine that to linden interop and
> not use it as our core REST format.
LLSD is super extra verbose for a wire protocol, so +1.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
=== message truncated ===
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080514/414e2325/attachment-0001.html>
More information about the Opensim-dev
mailing list