such a solution.
-- Dirk/Bart
-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
Gesendet: Donnerstag, 19. Februar 2009 03:27
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
On Thu, Feb 19, 2009 at 09:44:32PM -0500, Frisby, Adam wrote:
I'm using Project-Voldemort(.com) for the new osgrid server - it can be cross
compiled into C# via IKVM and works just fine. It's newish, but it's got some
very nice promising features and it's pretty damn fast.
How well does it
permanently wipe assets.
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de] On Behalf Of Eugen Leitl
Sent: Friday, 20 February 2009 1:26 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] oddities with asset
i thought the reasoning goes also the other way around:
if someone has a use case where they'd benefit from using Tahoe with
OpenSim, they are free to do it
if it doesn't give much benefit for OpenSim otherwise, that doesn't
matter, as long as people who want to use it can,
-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
Gesendet: Donnerstag, 19. Februar 2009 08:46
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
Dirk Krause wrote:
Glad you asked :-).
I would do a mixture
:29:10 +0100
From: eu...@leitl.org
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] oddities with asset storage
On Thu, Feb 19, 2009 at 10:24:40AM +0100, Dirk Krause wrote:
As soon as you buy it, the asset gets copied to your regions asset
repository (if it is something
: Re: [Opensim-dev] oddities with asset storage
Ok, then in my naive little world this would be the cloning business case
with some kind of quality of service.
Basically you only sell me a link to your variety of assets. Then we have
three cases:
- you keep this in your personal assets store
I think somekind of hybrid of different strategies might work well. Maybe
each storage provider could keep the assets in database and use hash to
ensure there is no duplicates and a separate metadata entry which is ref
counted with the binary. Anyhow this would be up to the specific storage
That won't wash.
If i give copy perm just because i need it to be no trans, that
doesn't mean that I condone off-grid use or personal backup. It has
to be separated from the perms as we know them.
Most clothing is no mod/no trans. That doesn't mean that the
clothing creator would want me to
No one would sue over a $0.05 shirt. The point of technical copy
protection is not to block copying. It is to make it require
criminal energy.
You can't do it accidentally, or because you don't know better, it
prevents casual copying. You need to invest criminal energy,
either by downloading
Dirk Krause wrote:
Hi,
I did a little test with a fresh OpenSim installation (yes, thanks for
the installer!),
to get a grip on what I learned from Melanie yesterday.
I wrote a little python script to help me monitor these tables:
inventoryStore/inventoryItems
assetStorage/assets
...
This would mean that any grid runs into a severe problem over time.
Yep :). On a standalone one could implement some cleanup scheme
which checks everything to see
if an asset is still referenced, and deletes that asset if it is not.
In grid mode this is a much more difficult problem
Date: Wed, 18 Feb 2009 16:37:12 +0100
From: dirk.kra...@pixelpark.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] oddities with asset storage
...
This would mean that any grid runs into a severe problem over time.
Yep :). On a standalone one could implement some
Dirk Krause wrote:
...
[...]
But isn't that ... horrible? (in lack of a better/worse word.)
As I said yesterday, IMHO there is no real need to think about
optimizations when you have
a serious blocker like this. I would even go so far that this is a major
roadblock for grid based
We can't step away from SL compatibility until there is a
full-featured, viable viewer, preferably not based on Linden Labs
code. Until then, the viewer's asset caching mechanism make that
impossible.
Melanie
Dirk Krause wrote:
...
This would mean that any grid runs into a severe problem
von Melanie
Gesendet: Mittwoch, 18. Februar 2009 19:57
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
Making a copy is the greater evil. With implicitly shared assets,
only content creators create assets. With asset copying, each
sale/give creates assets
...@pixelpark.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] oddities with asset storage
There could be business modell attached to it.
Lets say you sell only the 'right to use it for a given time' to the user,
then you would have only one set of assets with multiple inventory
-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
Gesendet: Mittwoch, 18. Februar 2009 20:42
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
In the viewer, the following are true:
- The asset ID attached
21:21
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
There are several viewer being developed already and their authors
are aware of requirements and responsive to different needs.
Mainly, any new viewer will be able to accommodate changes quickly,
unlike
, 18. Februar 2009 21:52
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
My goal in starting this whole discussion in the first place was two fold.
Fold 1: Get us considering how to evolve OpenSim so that assets database
currently containing 1.5million
Auftrag von Charles Krinke
Gesendet: Mittwoch, 18. Februar 2009 21:52
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
My goal in starting this whole discussion in the first place was two fold.
Fold 1: Get us considering how to evolve OpenSim so that assets
21 matches
Mail list logo
