I've added AssetsExist to master. It's implemented using REST, at
/get_assets_exist.
Regarding getting server capabilities: later I realized that Hypergrid
already has the helo command, which serves this purpose. Currently it
returns only one type of property: whether the server is based on
Yep, that's exactly its purpose. Feel free to add more info in the response.
On 4/2/2014 12:11 AM, Oren Hurvitz wrote:
I've added AssetsExist to master. It's implemented using REST, at
/get_assets_exist.
Regarding getting server capabilities: later I realized that Hypergrid
already has the
I already implemented SimianAssetServiceConnector.AssetsExist(). But since
I didn't change Simian itself, it works by simply calling GetMetadata() to
check if each asset exists. You can either leave this as-is, or implement
an explicit AssetsExist operation that checks all the assets at once, like
excuse my ignorance here but are these changes directly to the asset server
itself or are these simulator level changes?
On Wed, Apr 2, 2014 at 11:46 AM, Oren Hurvitz or...@kitely.com wrote:
I already implemented SimianAssetServiceConnector.AssetsExist(). But since
I didn't change Simian
Thanks. I'll take a look at what you've got. It's pretty easy to add the
call to the Simian services. PHP you know. I don't have to screw around
with http path prefix matching or anything... :-)
--mic
On Wed, Apr 2, 2014 at 8:46 AM, Oren Hurvitz or...@kitely.com wrote:
I already implemented
The actual work is done in the assets server, and there's code in the
simulators to call this API.
On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev]
ml-node+s2196679n7579160...@n2.nabble.com wrote:
excuse my ignorance here but are these changes directly to the asset
server
or are these simulator level changes?
View this message in context: Re: Optimize pushing assets to other
grids
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579162.html
Sent from the opensim-dev
I have implemented this method. I found that the Assets Service already had a
method to check for assets' existence, so I just had to extend it to check
multiple asset ID's at once, and make it available remotely. But now I'm not
sure what to do about backwards compatibility.
I'm sending the
Hi Oren,
the correct way is to create an additional post handler that is reachable at a
different URL, e,g, /AssetQuery/
Servers that don't implement it would return 404. Don't try to shoehorn this
functionality into the existing post handler.
Melanie
On 31 Mar 2014, at 13:55, Oren Hurvitz
+1 Melanie!
Functions are way too overloaded in OpenSim in general.
On Mon, Mar 31, 2014 at 8:50 AM, Melanie mela...@t-data.com wrote:
Hi Oren,
the correct way is to create an additional post handler that is reachable
at a different URL, e,g, /AssetQuery/
Servers that don't implement it
As this is an assets-service request, it belongs in the assets-service
handlers. They already handle many different requests: data, metadata,
data+metadata, store, update.
Creating a new handler would be easier for me at this moment, but perhaps
not best for OpenSim in the longer term. First,
This isn't overloading: it's an RPC endpoint that accepts many methods. You
wouldn't create a separate endpoint for each method, would you?
--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html
Sent from the
Then the solution is to generalize the code, not to overburden it. If
handling different URI forces dupe code then there was a very bad decision
made very long ago.
I bet it is threaded crap.
On Mon, Mar 31, 2014 at 9:00 AM, Oren Hurvitz or...@kitely.com wrote:
As this is an assets-service
This isn't designed as RPC, it's designed as REST. One URL/VERB
combination for each function.
We wanted to get away from the RPC concept. Let's not take backwards
steps here.
Melanie
On 31/03/2014 15:15, Oren Hurvitz wrote:
This isn't overloading: it's an RPC endpoint that accepts many
This isn't designed as RPC, it's designed as REST. One URL/VERB
combination for each function.
We wanted to get away from the RPC concept. Let's not take backwards
steps here.
Melanie
On 31/03/2014 15:15, Oren Hurvitz wrote:
This isn't overloading: it's an RPC endpoint that accepts many
Seems reasonable to me...A design approach I would have taken.
One question. Is there some sort of versioning built into the protocol?
One verb yes, but the dictionary numbers the definitions.
On Mon, Mar 31, 2014 at 12:35 PM, Melanie mela...@t-data.com wrote:
This isn't designed as
There is no implicit versioning in the actual request protocol. That
would have been impossible to maintain in the long run. Instead,
there is a protocol version. We can bump it when there are
incompatible changes on any protocol and it invalidates all of them.
So a sim version 7 will refuse to
If you say that the intention was to use REST then of course I accept what
you say. But whatever the vision was, the implementation today is very
different: many services use RPC. The /auth endpoint, for example, handles
6 methods. The /avatar endpoint handles 5 methods. And that's just for
Because even if badness exists, that is not a reason to add more
badness. Let's do future additions the right way.
Melanie
On 31/03/2014 18:52, Oren Hurvitz wrote:
If you say that the intention was to use REST then of course I accept what
you say. But whatever the vision was, the
A bit of a mixed bag that. I would have gone for an even-odd invalidation.
You have one full cycle to comply. But at least that doesn't leave sims
twisting in the wind.
On Mon, Mar 31, 2014 at 12:51 PM, Melanie mela...@t-data.com wrote:
There is no implicit versioning in the actual request
Besideswasn't backwards compatibility a problem?
On Mon, Mar 31, 2014 at 12:54 PM, Melanie mela...@t-data.com wrote:
Because even if badness exists, that is not a reason to add more
badness. Let's do future additions the right way.
Melanie
On 31/03/2014 18:52, Oren Hurvitz wrote:
If
The Hypergrid protocol is, unfortunately, full of RPC calls. If I had to
do it today, I would have done it with REST instead. When I started
doing it, we still didn't have the nice architecture that we have today.
Having said that, it's true that many of the REST handlers are
essentially RPC
rest handlers sounds good, is it documented somewhere ?
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
I originally put in the MajorInterfaceVersion back in 2008 but I now think that's a very bad way to handle updates in a
distributed system with no central control.
Instead, just like the web, the protocol should be designed with extensbility in mind so that the system can evolve
without
I want to improve how assets are transferred between grids in the Hypergrid.
Currently there are two ways this is done: push and pull. In both cases,
HGUuidGatherer is used to find all the assets that are embedded in the
top-level asset. The Pull operation is efficient because it won't load from
+1
On 3/30/2014 7:47 AM, Oren Hurvitz wrote:
I want to improve how assets are transferred between grids in the Hypergrid.
Currently there are two ways this is done: push and pull. In both cases,
HGUuidGatherer is used to find all the assets that are embedded in the
top-level asset. The Pull
-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Sunday, March 30, 2014 10:48 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Optimize pushing assets to other grids
I want to improve how assets are transferred between grids in the Hypergrid.
Currently there are two ways
It's already possible to know which assets are on the server by performing
GETs, so this method doesn't change the security situation.
--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579096.html
Sent from the
Indeed.
And the asset service that's exposed for the Hypergrid is not the one
that serves the grid internally. There are two separate services. The HG
Asset Service can be configured in all sorts of ways, from very
permissive to very restrictive, all under the control of the grid operators.
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Sunday, March 30, 2014 11:39 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Optimize pushing assets to other grids
It's already possible
: Sunday, March 30, 2014 11:39 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Optimize pushing assets to other grids
It's already possible to know which assets are on the server by performing
GETs, so this method doesn't change the security situation.
--
View this message
31 matches
Mail list logo
