http://opensimulator.org/api.php?action=feedcontributions&user=Awebb&feedformat=atomOpenSimulator - User contributions [en]2024-03-29T05:58:37ZUser contributionsMediaWiki 1.19.9http://opensimulator.org/wiki/IRCBridgeModuleIRCBridgeModule2008-11-04T16:34:34Z<p>Awebb: </p>
<hr />
<div>== Configuring IRCBridgeModule ==<br />
<br />
<code>IRCBridgeModule</code> allows you to relay chat from your OpenSim region to an IRC channel and vice versa. You can use this module to <br />
<br />
* make in-world chat available via a text-only interface such as IRC<br />
* control objects from IRC channels<br />
* use in-world objects to control bots attached via IRC<br />
* ...<br />
<br />
<code>IRCBridge</code> can be used in three modes: <br />
<br />
* in [[#Traditional IRCBridge mode|''traditional mode'']] where we relay all in-world chat from all regions to a single IRC channel on a single server, or<br />
* in [[#Multi-channel mode|''multi-channel mode'']] where we can relay in-world chat from a specific region to a specific channel (or even to a specific server)<br />
* in [[#Object chat relay mode|''object chat relay mode'']] where we only relay chat to and from private in-world channels<br />
<br />
In addition, we can [[#In-World Configuration|send commands]] to <code>IRCBridge</code> from in-world objects to re-configure <code>IRCBridge</code><br />
<br />
== Traditional IRCBridge mode ==<br />
<br />
In the traditional <code>IRCBridge</code> mode ("traditional" because<br />
that was the original <code>IRCBridge</code> ''modus operandi'') all<br />
in-world avatar chat from all regions is relayed to a specific IRC<br />
chat channel on a specific server. Chat from an avatar is reported by<br />
an OpenSim powered ''IRC bot'' in the IRC channel. Chat originating on the<br />
IRC channel is reported via "voice of god" in all regions (voice of<br />
god meaning that the in-world avatars will "hear" the chat but won't<br />
be able to see the originator anywhere in the region). <br />
<br />
To configure <code>IRCBridge</code> for traditional mode operation use<br />
the following configuration section in your <code>OpenSim.ini</code><br />
file (modifying as necessary, of course): <br />
<br />
<pre><br />
[IRC]<br />
enabled = true ; you need to set this otherwise it won't connect<br />
server = some.irc.server.net<br />
nick = OpenSinBot<br />
channel = #opensin<br />
port = 6667<br />
relay_chat = true<br />
report_clients = true<br />
<br />
commands_enabled = false<br />
command_channel = 4711<br />
access_password = WuffWuff<br />
<br />
relay_private_channels = false<br />
relay_private_channel_out = 4712<br />
relay_private_channel_in = 4713<br />
<br />
<br />
;fallback_region = name of "default" region<br />
;MSGformat fields : 0=botnick, 1=user, 2=region, 3=message<br />
; must start with "PRIVMSG {0} : " or irc server will get upset<br />
;for <bot>:<user in region> :<message><br />
msgformat = "PRIVMSG {0} :<{1} in {2}>: {3}"<br />
;for <bot>:<message> - <user of region> :<br />
;msgformat = "PRIVMSG {0} : {1} [{2}]: {3}"<br />
;for <bot>:<message> - from <user> :<br />
;msgformat = "PRIVMSG {0} : {3} - from {1}"<br />
<br />
</pre><br />
<br />
Let’s go through the list of configuration options:<br />
<br />
{| align=”center” border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! configuration variable<br />
! explanation<br />
|-<br />
| enabled <br />
| you need to set this to “true” otherwise <code>IRCBridgeModule</code> will not be enabled<br />
|-<br />
| server<br />
| the hostname of the IRC server that you intend to use<br />
|-<br />
| nick<br />
| the nickname which <code>IRCBridge</code> will use to connect to the IRC server <br />
|-<br />
| channel<br />
| the IRC channel to connect to<br />
|-<br />
| port<br />
| the port on the IRC server to conect to; this is usually port 6667<br />
|-<br />
| relay_chat<br />
| for traditional mode you need to set this to “true” to relay normal in-world chat <br />
|-<br />
| report_clients<br />
| if you set this to “true” then <code>IRCBridge</code> will notify the IRC channel whenever an avatar logs on, enters a region, leaves a region, and logs off<br />
|-<br />
| msgformat<br />
| select whichever message format you want <code>IRCBridge</code> to use for relaying in-world messages to the IRC channel.<br />
|-<br />
| commands_enabled<br />
| leave as is for traditional mode<br />
|-<br />
| command_channel<br />
| leave as is for traditional mode<br />
|-<br />
| relay_private_channels<br />
| leave as is for traditional mode<br />
|-<br />
| relay_private_channel_in<br />
| leave as is for traditional mode<br />
|-<br />
| relay_private_channel_out<br />
| leave as is for traditional mode<br />
|-<br />
| access_password<br />
| leave as is for traditional mode<br />
|-<br />
|}<br />
<br />
<br />
== Multi-channel mode ==<br />
<br />
With multi-channel mode we can configure <code>IRCBridge</code> to<br />
relay chat from different regions into '''different IRC channels''' — or<br />
even into '''different IRC channels on different IRC servers'''!<br />
<br />
The following <code>OpenSim.ini</code> configuration file extract<br />
configures <code>IRCBridge</code> to relay chat from ''region A'' into<br />
IRC channel <code>#opensin-A-opensim.server.net</code><br />
<br />
<pre><br />
channel = "#opensim-[%region]-[%host]"<br />
</pre><br />
<br />
Let’s take a closer look at what’s going on here:<br />
<code>IRCBridge</code> allows us to apply run-time variable<br />
substitution (a quite powerful mechanism).<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center"<br />
|-<br />
! align=”left” | configuration<br />
! align=”left” | explanation<br />
|-<br />
| width="40%" | channel = “#OS”<br />
| will connect all regions to the same channel; multiple opensim<br />
servers, specifying this same name would share the channel<br />
|-<br />
| channel = “#OS[%host]”<br />
| will connect all regions of a particular opensim server to the named<br />
channel; multiple hosts specifying this same pattern would each be<br />
connected to an unique host-name derived channel<br />
|-<br />
| channel = “#OS[%region]”<br />
| will result in each region being connected to a channel derived from<br />
the region's name; in effect, all regions will be connected to a<br />
unique channel; If two opensim servers were running an identically<br />
named region, then those regions would share the channel<br />
|- <br />
| channel = “#OS[%host]-[%region]”<br />
| will result in each server-region combination being connected to an<br />
unique channel; this offers the best guarantee of unique name across<br />
the internet as a whole <br />
|-<br />
| channel = “#OS[%region][%k]”<br />
| this configuration distinguishes consecutive activations of the same<br />
region by affixing an unique numeric to the end of the name<br />
|-<br />
|}<br />
<br />
In all of these examples, the square brackets are eliminated by the<br />
substitution process. The '%' prefix indicates that this is a run-time<br />
variable. A value in square-brackets and not preceded by '%' indicates<br />
that the value may have been supplied as a value in the IRC ini<br />
configuration. For example, the existing mechanism for naming the<br />
channel could be made unnecessary complicated by specifying: <br />
<br />
<pre><br />
channel = “[channelid]”<br />
channelid = “#my-irc-channel”<br />
</pre><br />
<br />
The substitution process is exhaustive, so a configuration variable<br />
name may be constructed from run-time values. <br />
<br />
To illustrate this, assume that the .ini file contains:<br />
<br />
<pre><br />
channel = “[#[%region]]”<br />
#brief1 = “#chatter-1”<br />
#brief2 = “#chatter-2”<br />
</pre><br />
<br />
Then region ''brief1'' will be connected to channel ''#chatter-1'', ''brief2''<br />
will be connected to ''#chatter-2'', and all other regions will connect to<br />
channels with names identical to their region names. This is a trivial<br />
example, but becomes more meaningful when we consider all of the other<br />
parameters that might need to be unique per region (server, port<br />
etc). Using this mechanism we can create an ini file that has unique<br />
settings for all aspects of IRC for each region. <br />
<br />
The following run-time values are available to this process:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center" <br />
|-<br />
! variable<br />
! explanation<br />
|-<br />
| %host<br />
| external host name associated with a region<br />
|-<br />
| %region<br />
| region name<br />
|-<br />
| %locX<br />
| X coordinate of the region.<br />
|-<br />
| %locY<br />
| Y coordinate of the region.<br />
|-<br />
| %master1<br />
| Master Avatar's first name<br />
|-<br />
| %master2<br />
| Master Avatar's last name<br />
|-<br />
| %k<br />
| A unique numeric assigned to this region, e.g. “0”<br />
|}<br />
<br />
Finally, a more comprehensive example of a configuration file; we are<br />
assuming that we have two regions, ''Wonky'' and ''Borked'': <br />
<br />
<pre><br />
channel = “[%region]”<br />
server = “[[%region]-server]”<br />
port = “[[%region]-port]”<br />
nick = “[[%region]-nick]”<br />
<br />
Wonky-server = irc1.server.org<br />
Wonky-port = 1234<br />
Wonky-nick = WonkyBot<br />
<br />
Borked-server = irc2.anotherserver.net<br />
Borked-port = 1234<br />
Borked-nick = BorkedBot<br />
<br />
</pre><br />
<br />
The ''Wonky'' region will connect to IRC channel <code>#Wonky</code> <br />
via port 1234 of IRC server <code>irc1.server.org</code> and <code>IRCBridge</code><br />
will appear as ''WonkyBot''. Our ''Borked'' region will connect to IRC channel<br />
<code>#Borked</code> via port 1234 of IRC server<br />
<code>irc2.anotherserver.net</code> using the nickname ''BorkedBot''.<br />
<br />
== Object chat relay mode ==<br />
<br />
In object chat relay mode <code>IRCBridge</code> relays messages from<br />
and to in-world channels.<br />
<br />
To configure <code>IRCBridge</code> for this mode you need to use the<br />
following configuration:<br />
<br />
<pre><br />
[IRC]<br />
enabled = true ; you need to set this otherwise it won't connect<br />
server = some.irc.server.net<br />
nick = OpenSinBot<br />
channel = #opensin<br />
port = 6667<br />
relay_chat = false<br />
report_clients = false<br />
<br />
commands_enabled = false<br />
command_channel = 4711<br />
<br />
relay_private_channels = true<br />
relay_private_channel_out = 4712<br />
relay_private_channel_in = 4713<br />
<br />
access_password = WuffWuff<br />
<br />
;fallback_region = name of "default" region<br />
;MSGformat fields : 0=botnick, 1=user, 2=region, 3=message<br />
; must start with "PRIVMSG {0} : " or irc server will get upset<br />
;for <bot>:<user in region> :<message><br />
msgformat = "PRIVMSG {0} :<{1} in {2}>: {3}"<br />
;for <bot>:<message> - <user of region> :<br />
;msgformat = "PRIVMSG {0} : {1} [{2}]: {3}"<br />
;for <bot>:<message> - from <user> :<br />
;msgformat = "PRIVMSG {0} : {3} - from {1}"<br />
<br />
</pre><br />
<br />
The important configuration variables here are:<br />
<br />
{| align="center" border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! configuration variable<br />
! explanation<br />
|-<br />
| relay_chat <br />
| needs to be disabled (well, you can keep it enabled if your in-world<br />
objects are silent and do not repeat what they heard)<br />
|-<br />
| report_clients<br />
| doesn’t really make sense if you’ve disabled relay_chat<br />
|-<br />
| relay_private_channels<br />
| needs to be set to “true”<br />
|-<br />
| relay_private_channel_in<br />
| all traffic from the IRC channel will be send on this private<br />
channel in-world<br />
|-<br />
| relay_private_channel_out<br />
| all chat on this private in-world channel is relayed to the IRC<br />
channel <br />
|-<br />
| access_password<br />
| set this to a password of your choice<br />
|-<br />
|}<br />
<br />
Your in-world objects then need to use LSL code along the following lines:<br />
<br />
<pre><br />
llSay(command_channel, “access_password,from,message”);<br />
</pre><br />
<br />
to send messages to the IRC channel.<br />
<br />
== In-World configuration ==<br />
<br />
The last feature worth mentioning is that you can control <code>IRCBridge</code> from in-world by sending commands on a specific command channel. <br />
<br />
To enable this feature you need to use the following configuration instructions:<br />
<br />
<pre><br />
commands_enabled = true<br />
command_channel = 4711<br />
</pre><br />
<br />
{| align="center" border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! configuration variable<br />
! explanation<br />
|-<br />
| commands_enabled<br />
| needs to be “true”<br />
|-<br />
| command_channel<br />
| set this to the private in-world channel number that you want to use<br />
|}<br />
<br />
<code>IRCBridge</code> understands the following commands:<br />
<br />
{| align="center" border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! configuration variable<br />
! explanation<br />
|-<br />
| server hostname<br />
| change to the new IRC server “hostname”<br />
|-<br />
| port port-number<br />
| change the port used to connect to the IRC server<br />
|-<br />
| channel channel-name<br />
| change the channel name used<br />
|-<br />
| nick new-nick<br />
| change the nick name used<br />
|-<br />
| client-reporting true|false<br />
| enable client reporting<br />
|- <br />
| in-channel channel-number<br />
| change relay_private_channel_in to channel-number<br />
|-<br />
| out-channel channel-number<br />
| change relay_private_channel_out to channel-number<br />
|-<br />
| close<br />
| close the IRC connection<br />
|-<br />
| connect<br />
| open the IRC connection<br />
|-<br />
| reconnect<br />
| close and re-open the IRC connection<br />
|}<br />
<br />
== irc_admin XmlRpc method ==<br />
<br />
<code>IRCBridge</code> supports one XmlRpc method that allows you to obtain the <code>IRCBridge</code>configuration for a specific region. To enable this method you need to enable the <code>[RemoteAdmin]</code> module.<br />
<br />
<code>irc_admin</code> expects two parameters:<br />
<br />
{| align="center" border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! parameter<br />
! explanation<br />
|-<br />
| password<br />
| the RemoteAdmin password<br />
|-<br />
| region<br />
| the region name for which you want to the IRC configuration<br />
|-<br />
|}<br />
<br />
it will return <br />
<br />
{| align="center" border="1" cellpadding="5" cellspacing="0"<br />
|-<br />
! parameter<br />
! explanation<br />
|-<br />
| server<br />
| the server name<br />
|-<br />
| port<br />
| the port name<br />
|-<br />
| user<br />
| the IRC user name being used<br />
|-<br />
| channel<br />
| the channel name being used<br />
|-<br />
| enabled<br />
| whether the IRC relay is enabled or not<br />
|-<br />
| connected<br />
| whether the IRC relay is connected or not<br />
|-<br />
| nickname<br />
| the current nickname<br />
|}<br />
<br />
here is sample python code showing how to invoke <code>irc_admin</code>:<br />
<br />
<pre><br />
import xmlrpclib<br />
s = xmlrpclib.Server('http://opensim.zurich.ibm.com:9000/admin')<br />
print s.irc_admin(dict(password = 'c00lstuff', region = 'zurela'))<br />
<br />
{'channel': '#opensim-lotus3d-zurela-opensim.zurich.ibm.com',<br />
'connected': True,<br />
'enabled': True,<br />
'nickname': 'lotus3dbot66',<br />
'port': '',<br />
'server': 'zurich.irc.ibm.com',<br />
'success': True,<br />
'user': "USER OpenSimBot 8 * :I'm an OpenSim to IRC bot"}<br />
</pre></div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T15:16:47Z<p>Awebb: /* Other Comments */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
<br />
I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
<br />
NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).<br />
<br />
Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.<br />
<br />
So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.<br />
<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)<br />
<br />
= Examples =<br />
<br />
it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..<br />
--[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)<br />
<br />
= Other Comments =<br />
<br />
I think it is important to separate the definition of an asset server, what it does, and what it communicates, from the specific mechanisms that will be employed. REST, XMLRPC, are all feasible, but I think it is very important that there be a recognizable interface between these notions. Like typing, protocols will come and go, the asset server's architecture should not be transport specific, or worse, transport dependent.<br />
--[[User:Awebb|Awebb]] 08:16, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T15:16:29Z<p>Awebb: New section: Other Comments</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
<br />
I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
<br />
NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).<br />
<br />
Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.<br />
<br />
So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.<br />
<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)<br />
<br />
= Examples =<br />
<br />
it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..<br />
--[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)<br />
<br />
== Other Comments ==<br />
<br />
I think it is important to separate the definition of an asset server, what it does, and what it communicates, from the specific mechanisms that will be employed. REST, XMLRPC, are all feasible, but I think it is very important that there be a recognizable interface between these notions. Like typing, protocols will come and go, the asset server's architecture should not be transport specific, or worse, transport dependent.</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T15:12:35Z<p>Awebb: /* Examples */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
<br />
I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
<br />
NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).<br />
<br />
Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.<br />
<br />
So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.<br />
<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)<br />
<br />
= Examples =<br />
<br />
it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..<br />
--[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T15:12:22Z<p>Awebb: New section: Examples</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
<br />
I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
<br />
NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).<br />
<br />
Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.<br />
<br />
So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.<br />
<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)<br />
<br />
== Examples ==<br />
<br />
it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..<br />
--[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:43:16Z<p>Awebb: /* Is the answer "both"? */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
<br />
I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
<br />
NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).<br />
<br />
Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.<br />
<br />
So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.<br />
<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:29:03Z<p>Awebb: /* Existing Technologies */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Leveraging Existing Infrastructure & Scalability =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:28:06Z<p>Awebb: /* Existing Technologies */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
= Existing Technologies =<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.<br />
--[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:27:44Z<p>Awebb: New section: Existing Technologies</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)<br />
<br />
== Existing Technologies ==<br />
<br />
Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:24:39Z<p>Awebb: /* Authentication */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:20:37Z<p>Awebb: /* Authentication */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere. Can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader?<br />
--[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:20:22Z<p>Awebb: /* Authentication */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
= Authentication =<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere. Can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader?</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:20:02Z<p>Awebb: New section: Authentication</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)<br />
<br />
== Authentication ==<br />
<br />
I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere. Can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader?</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:10:10Z<p>Awebb: /* Not Just Serving */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving : Asset Catalogs =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:09:39Z<p>Awebb: /* Not Just Serving */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
= Not Just Serving =<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:09:27Z<p>Awebb: /* Not Just Serving */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
== Not Just Serving ==<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings.<br />
--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:07:43Z<p>Awebb: /* Not Just Serving */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
== Not Just Serving ==<br />
<br />
The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe.--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:06:56Z<p>Awebb: New section: Not Just Serving</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)<br />
<br />
== Not Just Serving ==<br />
<br />
The focus of the page is upon retrieval of an identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe.--[[User:Awebb|Awebb]] 07:06, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T14:01:56Z<p>Awebb: /* Is the answer "both"? */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:58:44Z<p>Awebb: /* Is the answer "both"? */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.<br />
--[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:58:10Z<p>Awebb: New section: Is the answer "both"?</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Is the answer "both"? ==<br />
<br />
I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:46:11Z<p>Awebb: /* Metadata */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:45:39Z<p>Awebb: /* == Capability Cookies == */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
<br />
== Capability Cookies ==<br />
<br />
I like the idea of capabilities being packaged as cookies, that seems much more palatable than (ab)using the URI.<br />
--[[User:Awebb|Awebb]] 06:45, 9 October 2008 (PDT)</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:44:53Z<p>Awebb: /* Capability Cookies */</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
<br />
== == Capability Cookies == ==<br />
<br />
I like the idea of capabilities being packaged as cookies, that seems much more palatable than (ab)using the URI.</div>Awebbhttp://opensimulator.org/wiki/Talk:AssetServerTalk:AssetServer2008-10-09T13:44:05Z<p>Awebb: New section: Capability Cookies</p>
<hr />
<div>=Metadata=<br />
<br />
As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.<br />
<br />
Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --[[User:Jhurliman|Jhurliman]] 15:59, 6 October 2008 (PDT)<br />
<br />
== Capability Cookies ==<br />
<br />
I like the idea of capabilities being packaged as cookies, that seems much more palatable than (ab)using the URI.</div>Awebb