[Opensim-dev] About Processing on Assets Table (Discussion #2057)

Fri Aug 29 04:22:24 UTC 2008

Thanks a lot, Melanie, Michael and Sean!
OK, since it is a hard rule of protocol that assets are immutable and out of
our control, we have to keep it.
But I am really worried that let asset table increase without limit and
there is no way to clear garbage.
And I do not like the term asset here.  It could be matter, resource or even
object, etc.
I suggest that we could create a new table to save those which are really
assets.(TBD)
:-)

Well, the issue could turn to attachment processing.
*** 0 ***
I have to ask a primary question first.
Why the object is saved in prims, primshapes and primitems tables when it is
created on the grand,
but deleted from the 3 tables and saved in assets table when it is attached?

Actually, the object is saved in all the 4 tables when it is attached for
the first time and deleted from 3 primXXX tables when it is detached for the
first time.
But in memory, the object is always SceneObjectGroup's object no matter it
is on the ground or attached to the avatar.

*** 1 ***
Michael wrote
>If it is creating a new asset every time a user simple attaches/detaches a
prim, then it is something that should be looked at. As I don't think it
should be happening.
Exactly speaking, only detach makes it creating a new asset.
You know there is no process especially for saving the changes of an
attached object.
So, the detach process is doing the followings.
1. Detaches the attached object (deleting the object from scene, updating
avatar's inventory item)
2. Saves the latest information of the attached object to assets table by
creating a new asset and make avatar's corresponding inventory item change
its reference to the new one.
    Here I want to point out that in the following 2 conditions, this
process will make the previous asset garbage which is never be used and no
longer known by the world.
    A. the attached object changed but its asset only belongs to one avatar
    B. there is no changes on the attached object
I think it could resolve it checking whether the attached object has been
changed in condition b.
In condition A, it seems no way but to create a new asset because we should
keep the rule no update on asset.

*** 2 ***
Attachment point is saved in avatarattachments table, but other information
of attachment and other properties of the object are still saved in assets
table, such as
position(offset), rotation, shape, color, light, flexible path, texture,
script, etc., which can be edit in Edit Windows of Viewer.
I also noticed that the attachment info has been defined in class
SceneObjectPart but not Serializable.
        [XmlIgnore]
        public bool IsAttachment = false;
        [XmlIgnore]
        public LLUUID AttachedAvatar = LLUUID.Zero;
        [XmlIgnore]
        public LLVector3 AttachedPos = LLVector3.Zero;
        [XmlIgnore]
        public uint AttachmentPoint = (byte)0;
Could anyone explain the relationship of the two implements for attachment
info?

*** 3 ***
Although based on updating the existing asset, I am considering the
persistence of attachment.
I am discussing with Melanie in #2064, where Melanie wrote
>Currently, this is by design. There is no method to save changes during
edit, as that would create yet more asset bloat. It really should save on
closing the edit window, but we don't get a notification of that.
Function ProcessBackup() in class SceneObjectGroup is saving the prims
background.  Should we use it for reference?
I tried to make a patch but not completed for some problem.  And I will
attach the patch to #2064 for reference only later.

Thomas

2008/8/28 Sean Dague <sdague at gmail.com>

> Michael Wright wrote:
> > If it is creating a new asset every time a user simple attaches/detaches
> a prim, then it is something that should be looked at. As I don't think it
> should be happening.
> >
> > But as Melanie explain in the mantis issue, if a user makes a change,
> like changes the attachment point, then this does result in a new asset
> being created. Assets are sharable and as Melanie explained you never know
> who else has a refference to that asset. So you can't update it, as it would
> effect everyone who is using that asset.
> >
> > There has been talk in the past about lots of different possible changes
> to the asset system. But any big changes would need a lot of changes deep in
> the core of opensim.
> >
> > "Tao YANG (GMAIL)" <thomas.tao.yang at gmail.com> wrote: Hi everyone,
> >
> > I discussed this issue a little with melanie in Mantis #2057.  Thanks
> melanie!
> > Even though #2057 was turned into resolved, not fixable,
> > I still have some questions and want to discuss it with you all.
> >
> > Please allow me describe this issue again in brief.
> > I first noticed the problem when I was testing attachment using MySQL,
> > that "assets" table increased without limit if you attach/detach
> repeatedly.
> >   Reading source code, there is no real deleting, updating, but adding on
> the table.
> > So I report it in #2057 and tried to attach a patch.
> > And melanie explained the reason why assets cannot be updated or deleted.
> >
> >  The point could be whether the records in assets table can be updated or
> deleted.
> > 1. Is it good technically that asset table is increasing without any
> limit?
> >  2. In case of attachment, for example,
> >    if an attached object is not shared with others, after modifying or
> when
> >    detaching it, should we still create a new record in assets table,
> letting
> >    the previous one become garbage and never be used?
> >     I think the process on attachment should be improved.  But that could
> be based
> >    on how assets work.
>
> Also remember, assets being immutable is a function of the protocol.
> The client will never fetch an asset that it already has, so if you were
> to ever update an assets content you would need to force all viewers to
> clear their caches and restart their viewers.  This is a protocol
> optimization which may be good or bad, but it out of our control.
>
>        -Sean
>
> --
> Sean Dague / Neas Bade
> sdague at gmail.com
> http://dague.net
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080829/292e4bb8/attachment-0001.html>