[Opensim-dev] Object Representation

[Dzonatas]

Impalah wrote:
> Well, I've seen enterprise solutions with hibernate and Lucene working 
> together, so the needs for having a good search engine could be 
> covered with this aproach...

Recent slashdot news has pointed out a distributed database based on 
google, more to check-out:
http://www.linuxworld.com/news/2008/020608-hypertable.html
http://www.zvents.com/
http://code.google.com/p/hypertable/wiki/FAQ

>
> I've been looking for info of Atomatrix (not too much, only a bird's 
> eye look). Looks very interesting: atomic objects, distributed 
> computing, etc. Is all that a virtual world needs.

One thing that probably gets confused is the thought to implement 
everything in raw atomatrices, but that would be a resource hog 
space-wise even if it becomes extremely fast to index every detail of 
any possible object. A balance is needed. It is good to use atomatricies 
for general and dynamic areas, but specific data structures (especially 
ones that don't change) are not needed to be defined by atomatrices. 
Instead, a general type is made in a atomatrix structure, and it is used 
as a way to class blob entries. The blob then stores the packed data 
structure. That is why I pointed out the schema for the matrix1 example 
(previously posted here).

Hypertables (or hypercubes, multi-dimensional tables) are similar to 
what Atomatrix does. Atomatrix is more object-orientated based while 
hypetables is more 'view' based (i.e. MapReduce). I'd imagine the main 
different in schema is the resource use with Hypertables geared more 
towards search rather than update speed. Hypertables appears good for an 
archive base.

>
> But it's not incompatible with hibernate, I think. One is the object 
> model (the whole world architecture), the other, the way the objects 
> persists in database (or memory, or whatever we want to use). Maybe if 
> we take a look at the atomatrix code we could find a way to link 
> everything.

NHibernate is cool, but what I have seen so far is that it wants to 
broker directly to SQL and that forces users to base their entire 
environment on the NHibernate/SQL back-end. Anotherwords, it is not 
DB/filesystem agnostic. That is where I see it lack the generality we 
need; for example, when there is a need to share (as in exchange) 
objects between simulators. We can't expect all simulators to use 
NHibernate/SQL brokerage, but that doesn't mean we shouldn't use 
NHibernate. It means that assets being exchanged may break if the assets 
rely on the default setup of NHibernate of one simulator and find it not 
available on the other simulator.

Yes, it is not incompatible with Atomatrix. Atomatrix and NHibernate 
focus at different layers.  Atomatrix can easily encapsulate NHibernate 
data or even provide MapReduce like processes upon such data, but that 
depends on how well we would be able to get NHibernate not to rely on 
direct SQL access. It appears NHibernate has the XML option instead of 
SQL for storage, and XML is easily encapsulated. We would only want to 
be able to encapsulate objects that are not static to the run-time. Such 
static objects, being fitted with NHibernate and Mono, are best to let 
NHibernate do what it does natively. The more dynamic objects, being 
used as exchangeable assets for example, is where I see a more general 
layer is needed for their exchange, security, and other dynamic factory 
features.


>
> Collada is another thing. It's a xml format for saving 3D scenes: good 
> for sharing data between programs but not for having this data working 
> in real time. I tried to use it for my Henshin project (Autocad to 
> Second Life exporter program) but due the way SL treates the 
> primitives (modifications, cuts, texturing...) is a mad to use it: we 
> will need to add some type of "converter" if we want to use the Second 
> Life viewer. One project that uses Collada for importing/exporting is 
> Multiverse (http://www.multiverse.net/) if my memory doesn't fails.

Collada doesn't force anybody to use it natively, but it is a standard 
way to encapsulate such related data for exchange.  The filters (i.e. 
'converters') can be used to move data structures from one optimal 
format to another and back to collada for its exchange. The default 
schema shown on the website is pretty general and not well suited for 
more secure transactions. For example, parts of an object may be owned 
by several users, and we wouldn't want to generally expose all parts of 
an object for anybody to look at it. Collada does present the flow and 
basic protocol (skeleton) to allow such finer security control, but we 
would need to developer the actual methods to control such data.  I 
really like the ability to store an optimized physical model and an 
optimized viewer model of the same object under the same DAE.


The main question to this thread was about a unified database plan, and 
the answer may come in different layers to the database. I suggested a 
couple general layers. There are suggestions here for more specific 
layers.  How unified does it have to be?