Um, that's basically what the 'stable' and 'post-fixes' should be considered -
so basically, we should have found a good rev and bumped up to 0.6.3 before
doing any destabilizing work.
Good fixes still can go into the corresponding post-fixes branch, so basically,
the post-fixes should be
Hi,
One example is here http://realxtendserver.svn.sourceforge.net/. Choose
Authentication. There is NHibernateHandler and under that is Bulk.
Best,
- Antti
2009/2/16 Tommi Laukkanen tommi.s.e.laukka...@gmail.com
Hello
It would be nice to have somekind of short term solution to fix the
Again, I'd like to stress that I believe this is too dangerous to do
for anything other than textures.
It is also not really needed for things other than textures, since
the other assets are comparatively small, textural data.
I would not want to risk even the smallest chance of a hash
Hence me suggesting stronger hashes - there's no known attacks on anything
above or equal to 160bit, plus to calculate an attack you'd have to have the
hash of the original to begin with, which shouldn't be something revealed to an
end user.
Adam
-Original Message-
From:
Hi Ruud,
Here are some of the features currently set in stone for development..
DeepThink seems to be setting the foundation for groups.. making sure it
functions correctly ... If any developers would like to add on to this, that
would be great.
Groups Group Chat Group Permissions Group Titles
Hello
That works if we have property accessors directly exposed from AssetBase to
all metadata fields. Then we can write mapping with those accessors and
ignore the metadata aggregate.
regards,
Tommi
On Mon, Feb 16, 2009 at 1:54 PM, Mike Mazur mma...@gmail.com wrote:
Hi,
On Mon, Feb 16,
Plus you could use those hashes to distribute the assets to several backed
databases in similar manner as hashmap works. If a database becomes too full
you can always split it to sub databases and move assets there in analogy
with hashmap internal datastructure. Basicly all hashmap performance
Hello,
that was a typo. The correct word was textual. All asset types
besides textures are text.
Melanie
Charles Krinke wrote:
Sorry, the other assets are not just small texture data. We have
terrainImages, amongst other things.
Our assets table in OpenSim contains lots of things
This is a great thread y'all keep up the great work :)
Mike, all I have to say to you about this is *Thank you SO much* :)
Cheers
On Mon, Feb 16, 2009 at 8:39 AM, Michael Huntington mellom...@gmail.comwrote:
Hi Ruud,
Here are some of the features currently set in stone for development..
No. Terrain images are textures. They are assets referring to jp2
streams. That makes them textures. And, AFAIK, all other assets are
text.
Melanie
Charles Krinke wrote:
I am so sorry that we are having communications difficulties.
Terrain Images, are, I believe, neither textual nor text.
I know this isn't a viewer related dev group... but...I was wondering if
anyone was building a viewer that wasn't so tied down to SecondLife?
Basically a viewer that has been built from the ground up with OpenSim in
mind.
The viewers so far have been the biggest OpenSim eyesore for me... if anyone
Dear Mike:
As Dahlia said, the IdealistViewer is a good candidate as it begins to add
features. Many of us have high hopes for IdealistViewer during the course of
this year.
As OpenSim, we have decided to stay in SecondLife viewer compatible so we are
measuring the operation and performance
Yes, I did forget sounds. Probably because they never reached
critical mass on any system I have anything to do with. Though, a
lot seem to exist, judged by the number of gestures.
As for images, I call them all textures, because any image could
be used as a texture. They are all jp2 steams, so
And that I am in 100% agreement on.
Melanie
Charles Krinke wrote:
Well, it really doesnt matter what one calls them. Binary data, text,
whatever.
The point is that we have a number of issues with our assets table in OpenSim
that a bit of thought would help.
1. We have a significant
14 matches
Mail list logo
