On 16/11/12 07:34, Snowcrash Short wrote:
On Fri, Nov 16, 2012 at 6:23 AM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
...
There is also an assets/<asset-id>/metadata URL available that would return
asset ID if one is willing to rely on
this. Unfortunately, this is not yet documented.
That could be very useful, currently I'm using GET on the asset service in
order to determine if the asset already
exists, which is a bit overkill, ideally the web service would support "HEAD"
but a meta data check would/should work
equally well.
I'll try and doc this when I get time on [1]. You can also see the format in
OpenSim/Services/Connectors/Asset/AssetServicesConnector.
[1] http://opensimulator.org/wiki/AssetService
I'm very happy to see experimentation in this field because it's a major
issue. And it's up to individuals to make
these decisions. But I would say OpenSimulator itself will remain with
default config options very similar to what
we have now (e.g. no service exposure).
On a final note - it's will be much easier if you make your code
BSD/MIT/Apache before releasing for interaction
with existing codebases with a similar license. AGPL is a wildly different
license.
Once the code is more stable the licence will be modified to BSD. AGPL was
selected by me in the hopes that any changes
would flow back to the original project (I know it doesn't have to) and prevent
wild forking until the dust has settled
a bit. I know that this won't deter the hardcore black hatters, but they
already have quite a toolset at their disposal.
The problem comes if you accept any patches under the AGPL. If you then want to relicense, unless you obtained
copyright transfer or an appropriate rights grant, strictly speaking you would have to clear it with each contributor.
Pragmatically speaking, you could probably get away with agreement of the biggest contributors (which would probably
just be you). I believe this is what VLC did with their recent relicensing to LGPL.
Another benefit of starting BSD is that people working on other similar codebases (such as OpenSimulator) don't have to
think twice before reusing any good code or being able to extract stuff into common libraries.
Indeed, this is a major bug bear of me with the Mumble/Whisper module, which was licensed under GPL. This prevents that
module ever being incorporated into core OpenSimulator.
[1]
http://opensimulator.org/wiki/__Feature_Proposals/__Deduplicating_Asset_Service
<http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service>
best regards
Snowcrash
On Thu, Nov 15, 2012 at 11:55 AM, Melanie <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Apparently, the extra entries are for more efficient upload. Unless
a grid specifies the policy they want, open download and the
inefficient upload mechanism will be in effect for it.
Melanie
On 15/11/2012 11:32, InuYasha Meiji wrote:
> Sorry, this is what I get for writing email at 5:31am. So you
are
> saying I would have to give you the gridinventory service link
in order
> to choose to suport this service. Ok then I guess I am goo
dfor now,
> just won't give that info out. Sorry I got confused.
>
> Inu.
>
>
> On 11/15/2012 4:44 AM, Snowcrash Short wrote:
>> Hi
>>
>> I've been working on a client side tool for decentralizing user
>> inventories, which I will release as an open source tool in
two weeks,
>> some of the features may be relevant to grid operators.
>>
>> The basic premise of the tool is that the inventory and the
backing
>> assets of the inventory items really should be controlled by
the user.
>> The tool is born out of a frustration of having visited a
number of
>> grids. Each visit to a new grid presents me with an empty
inventory,
>> and I can then spend time searching for suitable item,
clothing,
>> attachments and other accessories.
>>
>> For this purpose I have created a tool which will allow me to
backup
>> my inventory to a local cache and then upload the contents to
another
>> grid.
>>
>> If my tool becomes popular, both the upload and download
mechanisms
>> may have some impact on the grid-operators, hence this email
to serve
>> as a notice.
>>
>> The basic architecture is pretty simple, consisting of a
number of
>> import agents, which can import the users inventory and
backing assets
>> to a local database, and a number of upload agents which can
upload
>> inventory content to a specific account.
>>
>> Backup/Import
>> There are two import agents, one which will import .iar files
and one
>> which works very much like I believe "Stored Inventory" works,
which
>> can backup the inventory of an avatars inventory. Avatar
backup/Import
>> is governed by a policy. Currently there are two policies,
>> one complying with a very restrictive interpretation of the
Linden
>> Labs policy on backups, and a completely unrestricted policy,
where
>> anything that can be downloaded will be downloaded.
>>
>> When a new account is registered in MyInventory it checks if
the
>> account is for a Linden Lab grid and limits the choices of
policies to
>> policies suitable for LL's TOS, I cannot and do not know if
other
>> grids have similar policies, I can well imagine that Avination
has a
>> similar restrictions, and would like similar logic implemented
to
>> restrict the download. Any grid operator which would like to
have
>> backup governed by a more restrictive policy are invited to
notify me
>> and I will attempt to implement the policy prior to the first
release
>> of the source code. or supply patches at a later time.
>>
>> Upload/Export
>> MyInventory supports two mechanisms for uploading inventory
>> content, traditional upload using UDP/CAPS and direct access
to the
>> inventory and asset web-services.
>> Due to limitations in the UDP/CAPS protocol each upload will
create
>> new assets, and as of my latest read of the Open Simulator
code the
>> asset store does not support "single instance assets", i.e. it
does
>> not use a checksum to verify if the asset already exists, for
this
>> reason MyInventory prefers to upload using direct access to
asset and
>> inventory web-services.
>>
>> I would propose that the grids which chooses to support
MyInventory
>> augment their "GridInfoService" entries with the url's for the
asset
>> and inventory web-services, e.g.
>>
>> [GridInfoService]
>> assets = http://assets.osgrid.org
>> inventory = http://inventory.osgrid.org
>>
>> Best regards
>> Snowcrash
>>
>>
>> _________________________________________________
>> Opensim-users mailing list
>> [email protected]
<mailto:[email protected]>
<mailto:Opensim-users@lists.__berlios.de
<mailto:[email protected]>>
>> https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
>
>
_________________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
<mailto:Opensim-users@lists.__berlios.de
<mailto:[email protected]>>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
_________________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_________________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
