OpenSimulator:Introduction and Definitions-it - Revision history

MakoBot: Categorized into :Category:Italian Translations

2011-06-11T10:16:02Z

Categorized into Category:Italian Translations

Archimedix at 11:15, 16 December 2008

2008-12-16T11:15:33Z

Archimedix: /* UGAIM */

2008-12-11T22:45:07Z

‎UGAIM

Archimedix: /* UGAIM */

2008-12-09T22:27:07Z

‎UGAIM

Archimedix: /* UGAIM */

2008-12-09T20:25:07Z

‎UGAIM

Archimedix: /* Introduzione e definizioni di Opensimulator */

2008-12-09T19:43:32Z

‎Introduzione e definizioni di Opensimulator

Archimedix: /* Introduzione e definizioni di Opensimulator */

2008-12-09T18:25:53Z

‎Introduzione e definizioni di Opensimulator

Archimedix: New page: =Introduzione e definizioni di Opensimulator= Il progetto Opensim è una piattaforma flessibile che può simulare degli spazi virtuali tridimensionali. Questi spazi virtuali danno la poss...

2008-12-09T18:18:35Z

New page: =Introduzione e definizioni di Opensimulator= Il progetto Opensim è una piattaforma flessibile che può simulare degli spazi virtuali tridimensionali. Questi spazi virtuali danno la poss...

New page

=Introduzione e definizioni di Opensimulator=

Il progetto Opensim è una piattaforma flessibile che può simulare degli spazi virtuali tridimensionali.
Questi spazi virtuali danno la possibilità di creare, modificare, cancellare e scriptare dinamicamente oggetti (Primitive) -- alcuni dei quali, quando propriamente linkati, istruiscono il client 3D in modo da renderizzarli in nuovi modi.
http://opensimulator.org/skins/common/images/button_bold.png
As a demonstration of the power of this platform, it is coded in its default configuration to be compatible with the Second Life viewer application, released under GPL by Linden Lab.

Pretty consciously using the original design of the Linden Lab network, there were five major services which needed to be provided to any region that wanted to talk to the Linden viewer. These are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.

==UGAIM==

Each of the servers plays a very specific -- and vital -- role in the OpenSim system.

'''UserServer''': This is the server responsible for authenticating the user to the grid. What this means is that it is responsible for a very important task: it creates a session identifier for the client which can be used to authenticate requests to the other servers in the same grid, and associates that session identifier with a UUID. (This may involve a cryptographic authentication, OpenID authentication, or even the current Resident Name/Password authentication.)

'''GridServer''': This is responsible for authenticating something else to the grid: the regions. Because the grid is 2-dimensional, and because there are X,Y coordinates that each region thus has, it is necessary to ensure that particular X,Y coordinates are assigned properly (whatever 'properly' means to the grid in question -- but OpenSim's current default is to do two-way authentication with the region servers, based on a dual shared-secret scheme (called "incoming password" and "outgoing password"). Each region is assigned a UUID.

'''AssetServer''': This is essentially a WFRM database (write few, read many). Once an asset goes in, there are two things that you can say about it: One, it's got a UUID as a label... and two, it's in for life (although in future OpenSim development, unused assets may be detected and reaped). Sounds, textures, images, notecards, scripts, serialized inventory objects are added, and never modified again (they're "immutable"). If you decide that you need to change a graphic to be two pixels left of where it is for your virtual house's trim to look right, you have to upload a new asset, which gets a new UUID, and associate that new UUID with the texture. The old one stays there forever.

'''InventoryServer''': That's all well and good, of course, but if it's all jumbled up into a key-value database like that, then what's the point? How could you keep anything straight? The UUID may be great for a computer, but it doesn't have anything to do with a human-readable label -- and how does it keep track of where I put it? That's the job of a much different database server -- one designed for a lot of little writes and a lot of little reads. This is the Inventory server. It works by -- you guessed it -- linking UUIDs together. The User has a UUID, which is used to get his InventoryRoot folder's UUID, and the InventoryRoot has a list of UUIDs that it links to, and each of those that are folders have lists of UUIDs, and those that aren't contain a link to a UUID, a type, and a descriptive name for the asset. The inventory server also retains permission information about items in inventory.

'''MessagingServer''': This one came later, and it's not quite as essential as the first four. However, if you want the people using your simulator to be able to communicate with each other via anything other than the creation of sky-writing primitive letters, you need this. This keeps track of who's supposed to be able to listen to whoever else, keeps track of long-distance messages sent from one user to another (think 'SMS' for a real-world analogue), and keeps unread direct messages until they're read (also very much like SMS).

All of these servers are important, and because they're so important, they all share a specific property: There Can Be Only One (of each, known to any given region).

==Region==

Oh yeah, the Region. The Region runs physics, runs scripts (though this may one day be moved off of the Region), keeps track of objects in the scene, keeps track of any observers connected, and sends scene updates to all of the observers. To it, everything it knows about is a UUID. Every last little thing -- a user connected is a UUID, an observer is a UUID, its terrain heightmap is a UUID, an asset is a UUID, a primitive is a UUID, the script running is a UUID... get the picture? It's a glorified data processor.

A Region is, not to put too fine a point on it, a memory space and behavior simulator which can share its state with observers. In short, it is a 3-dimensional MUD.

OpenSim has two modes of operation -- they're called "standalone mode" and "grid mode" (there is also an experimental Hypergrid intergrid mode that we won't go into here). These modes are distinct only in where they get their UGAIM services from. In standalone mode, the region provides its own UGAIM service interfaces and these are run in a single process. In grid mode, each service is run in a separate process, and each process can in principle be run on a different machine.

In grid mode, the UGAIM servers are all run as centralized grid services. All of the users have to be known by all regions, for example, and also have to interact with the Grid itself (which is defined, somewhat arbitrarily, as a 2-dimensional map akin to township and range specification for real property). The region keeps a temporary cached copy of assets (currently set to 24 hours), but not a permanent local copy of its assets. Other entities such as users, messages, or inventory aren't peristently cached. In fact, region servers will opportunistically cache many things to reduce perceptual lag for the client.

← Older revision		Revision as of 10:16, 11 June 2011
Line 35:		Line 35:

	In grid mode, the UGAIM servers are all run as centralized grid services. All of the users have to be known by all regions, for example, and also have to interact with the Grid itself (which is defined, somewhat arbitrarily, as a 2-dimensional map akin to township and range specification for real property). The region keeps a temporary cached copy of assets (currently set to 24 hours), but not a permanent local copy of its assets. Other entities such as users, messages, or inventory aren't peristently cached. In fact, region servers will opportunistically cache many things to reduce perceptual lag for the client.		In grid mode, the UGAIM servers are all run as centralized grid services. All of the users have to be known by all regions, for example, and also have to interact with the Grid itself (which is defined, somewhat arbitrarily, as a 2-dimensional map akin to township and range specification for real property). The region keeps a temporary cached copy of assets (currently set to 24 hours), but not a permanent local copy of its assets. Other entities such as users, messages, or inventory aren't peristently cached. In fact, region servers will opportunistically cache many things to reduce perceptual lag for the client.
		+	[[Category:Italian Translations]]

@@ Line 20: / Line 20: @@
 '''InventoryServer''':Tutto questo va benissimo, ovviamente, ma se questo rimane criptato in un valore chiave all'interno di un database, quale è il punto? Come puoi mantenere tutto regolare? il UUID va benissimo per i computer ma non ha nulla a che fare con un etichetta leggibile dall'uomo e dove rimane traccia dove l'oggetto si trova? Questo è il lavoro per un database molto diverso: uno disegnato per per essere letto e scritto un po di volte. Questo è l'inventory server.Funziona (l'avrete già indovinato) linkando i singoli UUID insieme. Lutente ha un suo UUID, che è usato per leggere la sua cartella di base (Inventoryroot UUID) e la cartella base ha una lista di cartelle UUID dalla quale leggere, ciascuna cartella ha a sua volta un elenco di UUID di oggetti che sono poi linkati ad asset ed hanno un nome descrittivo.L'inventory server contiene anche le autorizazioni degli oggetti.
-'''MessagingServer''': This one came later, and it's not quite as essential as the first four.  However, if you want the people using your simulator to be able to communicate with each other via anything other than the creation of sky-writing primitive letters, you need this.  This keeps track of who's supposed to be able to listen to whoever else, keeps track of long-distance messages sent from one user to another (think 'SMS' for a real-world analogue), and keeps unread direct messages until they're read (also very much like SMS).
+Tutti questi servers sono importanti e siccome sono cosi' importanti, condividono una specifica proprietà: Devono essere UNICI
-All of these servers are important, and because they're so important, they all share a specific property: There Can Be Only One (of each, known to any given region).
+Tutti questi server sono importanti, e siccome sono così importanti, tutti condividono una specifica proprietà: ve ne può essere uno solo (di ciascuno, conosciuto da una determinata regione).
 ==Region==

@@ Line 18: / Line 18: @@
 '''AssetServer''': Si tratta essenzialmente di un WFRM database (scrivere pochi, leggere molti).Una volta che un asset (oggetto) viene inserito, succedono 2 cose: Uno, viene assegnato un UUID come etichetta ... e due, non è per la vita (anche se negli sviluppi futuri di OpenSim, asset inutilizzati potranno essere individuati e sfruttati).Suoni, texture, immagini, notecards, script, oggetti serializzati di inventory sono aggiunti, e mai più modificati (saranno "immutabili"). Se si ha necessità di modificare una grafica di soli 2 pixel a sinistra nella vostra casa virtuale, sarà necessario ricaricare un nuovo asset (un immagine) alla quale verrà assegnato un nuovo UUID e associato alla nuova immagine.Quello vecchio rimarrà per sempre.
-'''InventoryServer''': That's all well and good, of course, but if it's all jumbled up into a key-value database like that, then what's the point?  How could you keep anything straight?  The UUID may be great for a computer, but it doesn't have anything to do with a human-readable label -- and how does it keep track of where I put it?  That's the job of a much different database server -- one designed for a lot of little writes and a lot of little reads.  This is the Inventory server.  It works by -- you guessed it -- linking UUIDs together.  The User has a UUID, which is used to get his InventoryRoot folder's UUID, and the InventoryRoot has a list of UUIDs that it links to, and each of those that are folders have lists of UUIDs, and those that aren't contain a link to a UUID, a type, and a descriptive name for the asset.  The inventory server also retains permission information about items in inventory.
+'''InventoryServer''':Tutto questo va benissimo, ovviamente, ma se questo rimane criptato in un valore chiave all'interno di un database, quale è il punto? Come puoi mantenere tutto regolare? il UUID va benissimo per i computer ma non ha nulla a che fare con un etichetta leggibile dall'uomo e dove rimane traccia dove l'oggetto si trova? Questo è il lavoro per un database molto diverso: uno disegnato per per essere letto e scritto un po di volte. Questo è l'inventory server.Funziona (l'avrete già indovinato) linkando i singoli UUID insieme. Lutente ha un suo UUID, che è usato per leggere la sua cartella di base (Inventoryroot UUID) e la cartella base ha una lista di cartelle UUID dalla quale leggere, ciascuna cartella ha a sua volta un elenco di UUID di oggetti che sono poi linkati ad asset ed hanno un nome descrittivo.L'inventory server contiene anche le autorizazioni degli oggetti.
 '''MessagingServer''': This one came later, and it's not quite as essential as the first four.  However, if you want the people using your simulator to be able to communicate with each other via anything other than the creation of sky-writing primitive letters, you need this.  This keeps track of who's supposed to be able to listen to whoever else, keeps track of long-distance messages sent from one user to another (think 'SMS' for a real-world analogue), and keeps unread direct messages until they're read (also very much like SMS).

@@ Line 16: / Line 16: @@
 '''GridServer''': Questo è responsabile per l'autenticazione qualcosa di diverso alla rete: le regioni.Poiché la rete è bidimensionale, e siccome ogni regione ha le coordinate X e Y, è necessario garantire che una particolare coordinata x,y vengano assegnati correttamente (qualunque sia il mezzo 'corretto' per la griglia in questione) ma l'impostazione predefinita di OpenSim è costituita da 2 canali di autenticazione con il server di regione, basata su uno schema a password condivisa (chiamate "password di ingresso" e "password di uscita"). A ciascuna regione è assegnata una UUID.
-'''AssetServer''': This is essentially a WFRM database (write few, read many).  Once an asset goes in, there are two things that you can say about it: One, it's got a UUID as a label... and two, it's in for life (although in future OpenSim development, unused assets may be detected and reaped).  Sounds, textures, images, notecards, scripts, serialized inventory objects are added, and never modified again (they're "immutable").  If you decide that you need to change a graphic to be two pixels left of where it is for your virtual house's trim to look right, you have to upload a new asset, which gets a new UUID, and associate that new UUID with the texture.  The old one stays there forever.
+'''AssetServer''': Si tratta essenzialmente di un WFRM database (scrivere pochi, leggere molti).Una volta che un asset (oggetto) viene inserito, succedono 2 cose: Uno, viene assegnato un UUID come etichetta ... e due, non è per la vita (anche se negli sviluppi futuri di OpenSim, asset inutilizzati potranno essere individuati e sfruttati).Suoni, texture, immagini, notecards, script, oggetti serializzati di inventory sono aggiunti, e mai più modificati (saranno "immutabili"). Se si ha necessità di modificare una grafica di soli 2 pixel a sinistra nella vostra casa virtuale, sarà necessario ricaricare un nuovo asset (un immagine) alla quale verrà assegnato un nuovo UUID e associato alla nuova immagine.Quello vecchio rimarrà per sempre.
 '''InventoryServer''': That's all well and good, of course, but if it's all jumbled up into a key-value database like that, then what's the point?  How could you keep anything straight?  The UUID may be great for a computer, but it doesn't have anything to do with a human-readable label -- and how does it keep track of where I put it?  That's the job of a much different database server -- one designed for a lot of little writes and a lot of little reads.  This is the Inventory server.  It works by -- you guessed it -- linking UUIDs together.  The User has a UUID, which is used to get his InventoryRoot folder's UUID, and the InventoryRoot has a list of UUIDs that it links to, and each of those that are folders have lists of UUIDs, and those that aren't contain a link to a UUID, a type, and a descriptive name for the asset.  The inventory server also retains permission information about items in inventory.

@@ Line 12: / Line 12: @@
 Ciascun servers gioca un ruolo specifico (e vitale) nel sistema Opensim.
-'''UserServer''': Questo è il server responsabile dell'autenticazione degli utenti nella Grid. Questo significa
+'''UserServer''': Questo è il server responsabile dell'autenticazione degli utenti nella Grid. Ciò significa che esso è responsabile di un compito molto importante: crea un identificatore di sessione per il client che può essere usato per autenticare le richieste di altri server nella stessa grid, e che associa identificatore di sessione con un UUID (Ciò può comportare una autenticazione crittografica, autenticazione OpenID, o anche l'attuale Nome / password di autenticazione dei residenti.)
-'''UserServer''': This is the server responsible for authenticating the user to the grid. Ciò significa che esso è responsabile di un compito molto importante: crea un identificatore di sessione per il client che può essere usato per autenticare le richieste di altri server nella stessa grid, e che associa identificatore di sessione con un UUID (Ciò può comportare una autenticazione crittografica, autenticazione OpenID, o anche l'attuale Nome / password di autenticazione dei residenti.)
+'''GridServer''': Questo è responsabile per l'autenticazione qualcosa di diverso alla rete: le regioni.Poiché la rete è bidimensionale, e siccome ogni regione ha le coordinate X e Y, è necessario garantire che una particolare coordinata x,y vengano assegnati correttamente (qualunque sia il mezzo 'corretto' per la griglia in questione) ma l'impostazione predefinita di OpenSim è costituita da 2 canali di autenticazione con il server di regione, basata su uno schema a password condivisa (chiamate "password di ingresso" e "password di uscita"). A ciascuna regione è assegnata una UUID.
-−
-'''GridServer''': This is responsible for authenticating something else to the grid: the regions.  Because the grid is 2-dimensional, and because there are X,Y coordinates that each region thus has, it is necessary to ensure that particular X,Y coordinates are assigned properly (whatever 'properly' means to the grid in question -- but OpenSim's current default is to do two-way authentication with the region servers, based on a dual shared-secret scheme (called "incoming password" and "outgoing password").  Each region is assigned a UUID.
 '''AssetServer''': This is essentially a WFRM database (write few, read many).  Once an asset goes in, there are two things that you can say about it: One, it's got a UUID as a label... and two, it's in for life (although in future OpenSim development, unused assets may be detected and reaped).  Sounds, textures, images, notecards, scripts, serialized inventory objects are added, and never modified again (they're "immutable").  If you decide that you need to change a graphic to be two pixels left of where it is for your virtual house's trim to look right, you have to upload a new asset, which gets a new UUID, and associate that new UUID with the texture.  The old one stays there forever.

@@ Line 6: / Line 6: @@
 Come dimostrazione della potenza di questa piattaforma, è stata scritta nella sua configurazione di default, per essere compatibile con il client di Second Life, rilasciato dalla Linden Lab sotto licenza GPL
+Abbastanza consapevolmente con l'originale struttura di rete della Linden Lab, sono necessari 5 servizi maggiori da fornire alle regioni che vogliono essere connesse con il client di Linden.
-Pretty consciously using the original design of the Linden Lab network, there were five major services which needed to be provided to any region that wanted to talk to the Linden viewer.  These are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.
+Quste sono conosciute con l'acronimo UGAIM, ovvero : User, Grid, Asset, Inventory, Messaging
 ==UGAIM==
-Each of the servers plays a very specific -- and vital -- role in the OpenSim system.
+'''UserServer''': Questo è il server responsabile dell'autenticazione degli utenti nella Grid. Questo significa
-'''UserServer''': This is the server responsible for authenticating the user to the grid.  What this means is that it is responsible for a very important task: it creates a session identifier for the client which can be used to authenticate requests to the other servers in the same grid, and associates that session identifier with a UUID.  (This may involve a cryptographic authentication, OpenID authentication, or even the current Resident Name/Password authentication.)
+'''UserServer''': This is the server responsible for authenticating the user to the grid. Ciò significa che esso è responsabile di un compito molto importante: crea un identificatore di sessione per il client che può essere usato per autenticare le richieste di altri server nella stessa grid, e che associa identificatore di sessione con un UUID (Ciò può comportare una autenticazione crittografica, autenticazione OpenID, o anche l'attuale Nome / password di autenticazione dei residenti.)
 '''GridServer''': This is responsible for authenticating something else to the grid: the regions.  Because the grid is 2-dimensional, and because there are X,Y coordinates that each region thus has, it is necessary to ensure that particular X,Y coordinates are assigned properly (whatever 'properly' means to the grid in question -- but OpenSim's current default is to do two-way authentication with the region servers, based on a dual shared-secret scheme (called "incoming password" and "outgoing password").  Each region is assigned a UUID.

@@ Line 3: / Line 3: @@
 Il progetto Opensim è una piattaforma flessibile che può simulare degli spazi virtuali tridimensionali.
 Questi spazi virtuali danno la possibilità di creare, modificare, cancellare e scriptare dinamicamente oggetti (Primitive) -- alcuni dei quali, quando propriamente linkati, istruiscono il client 3D in modo da renderizzarli in nuovi modi.
-http://opensimulator.org/skins/common/images/button_bold.png
-As a demonstration of the power of this platform, it is coded in its default configuration to be compatible with the Second Life viewer application, released under GPL by Linden Lab.
+Come dimostrazione della potenza di questa piattaforma, è stata scritta nella sua configurazione di default, per essere compatibile con il client di Second Life, rilasciato dalla Linden Lab sotto licenza GPL
 Pretty consciously using the original design of the Linden Lab network, there were five major services which needed to be provided to any region that wanted to talk to the Linden viewer.  These are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.