This should not currently be used in any circumstances except for experimentation.
Database tables used by this plugin can still change at any time with no migration path.
Some successful collision attacks have been carried out on sha1 with speculation that more are possible.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms
No successful attacks have been shown on sha256, which makes it less likely that anybody will be able to engineer an asset hash collision in the future.
Tradeoff is more storage required for hashes, and more cpu to hash, though this is neglible compared to db operations and network access.
Whether this is worthwhile is debatable since here we are not transmitting data over a network
In addition, jpeg2000 (the biggest data hog) is already a compressed image format.
May not remain.
This is an extremely crude implemenation which almost works by accident. Nevertheless it does work.
It can be tested with the instructions at http://opensimulator.org/wiki/Feature_Proposals/Deduplicating_Asset_Service#Testing
It does not interact at all with the existing asset service or any data stored there.
This code is subject to change without notice and should not be used for anything other than gawking.
MySQL and MSSQL have it as Sandbox, sqlite as sandbox.
In various different places in every plugin the wrong casing is used...
Consistency, who needs it? Or one day sqlite can change to Sandbox.
Telehub commits! They will eat your babies and corrupt your database while
they munch. DO NOT use anything from the first Telehub commit to this one.
FIRST GOOD COMMIT is the one FOLLOWING this one. You have been warned.
This is damage control es EstateSettings is not the place this can be put.
EstateSettings is nt unique to a region and therefore would introduce
a hard limit of one telehub per estate, completely shutting off the
option of having SL style telehubs, e.g. one per region. Whole
estate teleport routing can still be implemented id desiresd, this
way all options are open while the other way most options get closed
off.
Telehub settings now persist to the database and are saved across sim restarts. So-far this only works on MySQL. this is a work in progress, teleport routing is not yet implemented.
Using the RemoteAdmin API to close then recreate a region would fail if the estate name had not changed. If the estate name /was/ changed then the existing estate would be renamed rather than a new one being created. The problem really arose from a lack of distinction in the data storage layer between creating new estates and loading existing ones.
Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white.
On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero.
This commit resolves the problem by saving the default texture UUIDs instead of Zero.
However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed.
This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones.
However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
