bubble life cycle?

[Maróy Ákos]

Tommi,

Now I'm trying to implement a simple MXP server, based on the C++
implementation already available. My initial intention is just to create
a server which is quite transparent and does not do any persistence.
That is, it would start up, it would handle bubbles and clients that
connect to bubbles. it would accept injected objects and keep track of
them - and it would keep all connected parties updated about the changes
in the bubble.

As I'm sketching this up, I bumped into an issue of designing a bubble
life cycle - how are bubbles created, who creates them, does it belong
to anyone, etc. From what I see, a single server can serve multiple
bubbles, with the server having a default bubble to provide to joined users.

But, are bubbles themselves created inherently - is this outside of the
scope of MXP? But when I look at the bubble fragment description, there
I see an owner_id field, which would imply that bubbles belong to users
which join a server via a join request. would these users create the
bubbles in some way? if so - how?

Akos

[Tommi Laukkanen]

Hi

Sounds like fun :). Bubbles are configured to server via some other media than MXP. For example xml configuration files. OwnerId is not really used and it was meant to be used as marking certain user as administrator of some bubbles.

-tommi

--
You received this message because you are subscribed to the Google Groups "Metaverse eXchange Protocol" group.
To post to this group, send email to metaverseexc...@googlegroups.com.
To unsubscribe from this group, send email to metaverseexchangep...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/metaverseexchangeprotocol?hl=en.

[arkowitz]

We should think in terms of bubbles, participants, coordinate systems,
and hub processes. I think it is very important that processes for
handling the needs of participants in bubbles should be easily spawned
and easily augmented with additional spawning - for example as more
participants join the same bubble. This will make for a general
purpose cloud - in the process hosting, not MXP - sense. A cloud
spawning hub processes in response to user activity and completely
agnostic as far as what goes into the space bubbles it handles. The
participants choose what goes into the spaces. I am against even a
"default starting location" for a server. :)

A hub process can be spawned by the first participant wishing to visit
a designated space within a designated coordinate system. How that
space and system are defined can be xml, some website with a directory
on it, whatever; but the first participant requests a hub process be
spawned to serve that coordinate system and get the land content for
the place injected into it.

As more participants join, and as bubbles are spawned which are
defined as adjacent (via coordinate system to coordinate system
mapping formula within the xml directory), additional hub process can
be spawned to assist with the now more active bubble or its
"neighbours".

Arkowitz

On Feb 6, 3:35 pm, Tommi Laukkanen <tommi.s.e.laukka...@gmail.com>
wrote:

> Hi
>
> Sounds like fun :). Bubbles are configured to server via some other media
> than MXP. For example xml configuration files. OwnerId is not really used
> and it was meant to be used as marking certain user as administrator of some
> bubbles.
>

> > metaverseexchangep...@googlegroups.com<metaverseexchangepro­tocol%2Bunsu...@googlegroups.com>

[Tommi Laukkanen]

What Ben is proposing is really interesting architectural approach and implementing a prototype would give a lot of improvement ideas to protocol level.

As Ben pointed out there is no absolute coordinate system and this kind of space governance system should also rely on relative coordinates to avoid running out of range. One approach would be to have permanent landmark network which define locations relative to each other and you would reference space relative to this landmark network.

-tommi