Changes to Terminology

1. Evaluate using primary bubble to denote the bubble where object was injected in contrast to secondary bubble where object is replicated.

• > ACCEPTED

Theoretical Development

1. Evaluate whether channel prioritization should be supported by giving channels priorities and choosing messages to be send based on that priority.

1. Evaluate whether three phase handshake should be used to allow server to verify that the response packet it sent was transported correctly back to client instead of going immediately and possibly falsely to connected state after sending connection response.

1. Evaluate whether bubble should have veto on movement. In other words should all movement be done with request / response. In the same manner as inject.

• > Should the movement done by injecting location / orientation fragment of an object? (Tommi)
• > We should make it easy to embed a physics engine or other "vetoing" engine into the hub; as far as the protocol is concerned, this should be optional and veto only in effect if initial creation of bubble asked for it (ark)
• > agreed. the 'veto' could be a sanity check on the clients calculation of movement. it might be too much to as of the server in terms of CPU resources to do all the phyisics calculation for all clients. after all, all the clients form a wonderful distributed computing grid, let them do a calculation :). (akos)
• > another consideration could be some movements / events triggered by the server, instead of the client. this could include physics calculations, special events, or interaction events between clients (e.g. collisions, kills, etc.) (akos)
• > Does this mean that we should add no response required field to inject request or requests in general or that we should create move request and response pair which allows for this? Inject request might be more generic.
• > Request/response is handled by inject messages by injecting only necessary segment. Optimized situation is supported by allowing participant to send the optimized movement event to server instead of inject.
• > ACCEPTED

1. Consider global identification schemes. Global uuid register, best effort uuid generation with collision possibility and urls as ids. This has to be considered for participants, objects and assets. The url should resolve to xml document containing things like owner, inventory url etc.

• > Apply XRI: http://en.wikipedia.org/wiki/Extensible_Resource_Identifier (Tommi)
• > No comments so far. Do you agree that XRI is the way to go?
• > ACCEPTED

1. Consider methods for space governance in distributed bubble cloud. Access limits to given space including movement and injection. Ability to inject or move to space normal object, exclusively space reserving object, persistent object, immobile non physics respecting object? Limits to allowed object dimensions? Does this require changes to protocol or can it be handled through extension fragments and contracts between linked bubbles?

• > Move this to be handled in later version? (Tommi)
• > the concept of persistent objects goes against the grain, imho; every object must have a participant owner; persistence should be accomplished by a daemon participant, not the hub (ark)
• > how does this topic relate to scenery? (in my definition, scenery is a range of static objects that are 'agreed to' and shared by all participants, most usually installed locally for each of them) (akos)
• > MOVED (To architecture level discussion)

1. overlapping clouds & level of detail: consider very large bubble spaces, where the number of participants is too large to send all updates to each participant with high frequency. currently the concept is that each participant is connected to only one bubble at any one time, and that the bubble is responsible for sending relevant updates to each client. relevancy includes proximity to other objects, so most probably, updates related to close objects will be more frequent, while updates to far objects will be sparse. similarly, different levels of detail related to 3D representation will be sent for object of different distance - a less detailed 3D model for far objects, a more detailed one for close objects. at the end, from the bubble implementation perspective, this all comes down to slicing up the space into grids, and sending updates for participants within each grid with the highest frequncy, neighburing grids with a bit lower frequency, and all other grids with the least frequency. while this can be implemented within a bubble - why not take the approach to treat each such grid as a different bubble, and the participant can just subscribe to the ones relevant to him? this would move the taks of maintaining grid relevancy for each client from the server, to each client - thus distributing the load. (akos)

• > I am not sure I fully grasp how you would extend the current bubble cloud model unless you mean just allowing participants to connect to several bubbles. This would actually raise the server load as each server would have order of magnitude more connections. With current architecture servers connect each other and distribute information via single server to server connection and client has only one server connection. It is not forbidden in the current design that participant would connect several bubbles as well. It just requires more from the client implementation.
• > MOVED (To architecture level discussion)

Changes to Protocol

1. Evaluate adding ordered delivery functionality to guaranteed message channel. Can this be added on top of the existing layer with minimal changes in implementation?

• > After some reflection I am starting to think it would be good idea to make the entire guaranteed channel ordered to allow for rapid injection of interdependent object structures as kripken has requested. (Tommi)
• > Guaranteed seems to be relatively trivial. Ideally we could support several guaranteed channels which would all have ordered delivery feature. Guaranteed channels stalls until messages can be delivered in correct order. If we know that the message message delivery has to be guaranteed then it is highly likely that the order matters as well. Can anyone think any exceptions for this?
• > ACCEPTED

1. Evaluate adding time stamps to unguaranteed signal type messages to allow for time stamp based invalidation of late arriving signal messages.

• > I would say we should go with time stamp here and leave the details to the engine applying the signal. We would not want the message order changes between messages of different objects to translate to packet loss as would happen if we would use ordered channel. (Tommi)
• > Could we use channel concept here as well instead of time stamp. Define large enough channel space (int) so that each object may have unique unguaranteed transport channel. For example negative integers are guaranteed per object channels, zero is transport layer channel. Some of the positive channels can be reserved to certain guaranteed MXP message types and rest can be user assigned? (Tommi)
• > Seems possible to get the ordered functionality this way just by adding a "channel" field; we should have both the timestamp and the channel field I think; I also think we should have an IRC to talk specifically about channels and what new functionality the hub may need if any as opposed to client handling (ark)
• > don't we already have a timestamp for each packet (first send time)? would the channel concept be a subscription based approach - each client can subscribe to each channel as he sees it necessary? (akos)
• > Not all transport layers necessarily have timestamp.
• > Unguaranteed channels where we have use case for both ordered and not ordered delivery. Some of the transport layer messages like ACK's and Keepalives do not require ordered delivery. On the other hand all the unguaranteed mxp core messages (only movement currently) seem to be of the type signal. They transmit a continuous signal where order matters but late arriving messages can be discarded. This might suggest we divide unguaranteed channels to one control channel and N signal channels where each object has dedicated signal channel. The dedicated channel can be used for things like movement signal and animation signal. If we do this do we need separate guaranteed flag anymore or could this be deduced from the channel number. For example positive channels are guaranteed ordered channels and negative channels are signal channels. Zero channel would be the control channel. Signal type messages will also contain time stamp.
• > ACCEPTED

1. Evaluate whether message frame header sizes should be optimized by sending most of the information with first frame only. Rest of the frames could contain just message id and frame index.

• > this would mean that the 10-byte frame header would decrease to 6 bytes, I'm not sure saving on these 4 bytes make it worthwhile (akos)
• > REJECTED

1. Should we consider to define a TCP-based procol on the side, that can be used easily for less performance demanding applications, like integration into web sites using JavaScript? I'm thinking of a JSON-based serialization interface on top of a RESTful API, with basically the same message structures. simple clients could send in infrequent state updates easily, and one could easily create mash-ups, like Google Maps integration, etc. also, see EEML & patchube for real-world usage concepts on Augmented Reality: http://www.eeml.org/ , http://www.pachube.com/

• > ACCEPTED

1. Separate packet layer from payload frame encoding. This requires acks to be incorporated to packet header and control messages be changed to specialized packets.

• > ACCEPTED

Changes to Encoding

1. Evaluate need for standard binary format to present time stamp.

• > Do we need this and does such standard exist? (Tommi)
• > Our timstamps need not represent "the time"; I believe all they need to do is represent a point in the future, based on the hub's time; I had originally planned for the hub to keep track of the offset between it's time and each client's, and just translate timestamps (ark)
• > AFAIK the 'standard' time format is the UNIX time: http://en.wikipedia.org/wiki/Unix_time , which is the same we have now, expect for the epoch being January 1st 1970. I would vote for sending 'the time', as opposed to sending some arbitrary offset to the servers time (re ark), to make conversions easier, and also to make transfers between hubs easier. (akos)
• > ACCEPTED (unix time, unless you have objections ark)

Changes to Packet Structure

1. Evaluate whether time stamps are needed on packet level.

• > I am not sure just being able to measure message Jitter is worth it. (Tommi)
• > both jitter and packet relevancy (e.g. packets from too long ago just shouldn't matter) (akos)
• > There will be other transport layers in addition to UDP which will not have packets.
• > Hence we should not rely on packet time stamps on message relevancy. (Tommi)
• > ACCEPTED (If use case for packet level time stamp does not appear.)

1. Find better name for session_id field. For example stream_id could be better as sequence_id is different for upstream and downstream packets.

• > Stream id is probably good. (Tommi)
• > in 0.5, we don't actually have a sequence_id field (akos)
• > corrected to session_id (Tommi)
• > ACCEPTED

1. Create session id as aggregate of up and downstream ids.

• > ACCEPTED

Changes to Message Schematics

1. Evaluate whether application extensions could be divided to several segments which could be cached on bubble for full synchronization requests. This would allow efficient partial updates to objects using segments.

• > Multiple extension fragments per message and optional extension fragments. Core fragments could also be equal to the extension fragments in implementation level. For example inject message might only inject certain application extension and leave location/orientation fragment out. (Tommi)
• > This could be a very important feature; some objects may have huge number of attributes and would impact performance otherwise (ark)
• > I'm not sure I understand which extension fragments are we talking about here - sorry for my lack of understanding (akos)
• > ACCEPTED (implement if possible)

Changes to Message Serialization

1. Evaluate whether messages containing N-fragments should declare the amount of fragments in some kind of header fragment.

• > I'm all in for this one, would make implementations easier & nicer (akos)
• > NOT APPLICABLE (if we use google protocol buffers we do not need to worry about this)

1. Evaluate whether string field sizes should be changed from fixed to variable from 0 to defined maximum width. The actual field size in bytes would be defined by leading byte (string) or integer (text). This would decrease the serialized message sizes but make parsing more complicated as frame content would not be predefined anymore. Packet content would also be harder to read by humans as location of fields would not be fixed any more. This might also prove more challenging for any hardware optimization of hubs (pretty theoretical at this point). Both of these can be work around by placing string fields to end of message. This would in practice enforce message content agnostic multiplexing and demultiplexing of message data to/from packet frames via specialized streams. Performance penalty of byte array copies from frames to stream buffer could be avoided by implementing input stream which would allow reading of bytes directly from separate byte arrays of packets. This would keep the packets reserved until all the frames have been read from the packet.

• > for possibly long strings / text this would make sense. for example, some URL fields too short lengths now for some real-world applications. from an implementation perspective, I'm don't see this as a problem (akos)
• > NOT APPLICABLE (if we use google protocol buffers we do not need to worry about this)

1. Evaluate possibility of specifying message structure definition language which would allow for code generation of message valuable objects. The same system could be used to define extension fragment serialization.

• > Message structure definition language for messages, core fragments and extension fragments. Automatic generation of message code based on the message structure definitions. This would be a big leap in flexibility and would accelerate protocol content development. If we can keep the serialization cpu efficiency we have now then this would be great improvement. (Tommi)
• > Structure definition language sounds good provided it is not a pain to parse. Regarding variable length strings, if message structure definition language takes care of this then great; if not then I wonder why a really long string needs to be transmitted via the protocol; any really long content should be downloaded by the clients via http from the content definition layer (ark)
• > one could consider the protobuf library to be used for this purpose: http://code.google.com/p/protobuf/ but of course there are others. ark: long strings might be needed to be sent within the protocol, for example URLs might be long (definately longer that the current 50 characters in the spec) (akos)
• > ACCEPTED (google protocol buffers (GBF) unless show stoppers appear in further evaluation and implementation)

Changes to Messages Fields

1. Evaluate whether object should contain avatar flag to mark it as avatar object. As an optimization perception messages would be sent of objects which are inside perception range of avatar objects.

• > I think this would be good to have. One participant could have multiple objects flagged like this to indicate that they are used for active participation to world by the participant. Could the name be different from avatar? For example is_active_object? (Tommi)
• > If there is any attempt to make avatars special it will violate the very foundation of the protocol's architecture, imho. I think we need to consider another layer at this point - a layer of attributes which direct aspects of how things should be simulated within the client. I think it is important we get familiar with this next layer up, so that we add things to it that otherwise we would have been trying to cram into the base protocol. (ark)
• > ark: can you elaborate on the 'next layer'?
• > ACCEPTED (Observer flag to mark the perceptions should be relayed to the participant of the object.

1. Evaluate whether ObjectFragment should contain InventoryUrl as it is suggested that each object should have home inventory defined where object assets can be loaded from and where object is persisted.

• > I think this is needed. (Tommi)
• > I though every object already had to have a URL? (ark)
• > I think its a good idea (akos)
• > ACCEPTED (Apply XRI, i.e. put this url to xml document at the XRI location)

1. Evaluate whether object should contain persistent flag for deducing if bubble should host the object persistently. In other words whether object should disappear automatically when participant disconnects.

• > I think this is needed. (Tommi)
• > I do not think a bubble should ever host an object, or persist anything; there should be a daemon participant for this. The persistence flag is then an attribute within the next layer up, not within MXP. (ark)
• > interesting consideration - should bubbles 'host' anything, or should they really just reflect whatever is injected into them? I think it makes sense to be able to create a server / deaemon that has an MXP interface already, instead of having to run two daemons: one that hosts the objects, the other just being an MXP bubble (akos)
• > ACCEPTED

1. Evaluate whether object perception range should in included to object fragment.

• > I think this is needed. (Tommi)
• > Agreed; thought it was already there. (ark)
• > ACCEPTED

1. Change action observation radius to perception range.

• > I think this would be more in line with our chosen terminology.
• > ACCEPTED

1. Change action source object id to object index.

• > This would require index mapping when action propagates to next bubble. Probably best to use id here. But change field name from source object id to object id. (Tommi)
• > ACCEPTED (source object id to object id)

1. Evaluate whether disappearance event should use objectid instead of object index. In some situations delayed disappearance might not have objectindex available.

• > Object id would be symmetrical too. This a good change. (Tommi)
• > ACCEPTED

1. Evaluate removing owner id from bubble. No real use case. Owners may or may not want to mark their ownership and plain id is not anyway enough for this without global guid register. If this is needed one possibility would be to have openid identity url. Might be better to have separate method for accessing bubble metadata from bubble http service.

• > Probably clear away fields which are not really needed.
• > I think since bubbles are dynamic and much about them is determined at creation time by owner, it will be important for something somewhere to keep track of who owns the bubbles; perhaps this is a bubble directory service, however, and not the hub. (ark)
• > REJECTED

1. Evaluate whether TypeId is required in object and who upkeeps the register.

• > Should we change it to Type XRI url? (Tommi)
• > otherwise, how do we know what type of object are we getting info on? IMHO we need some kind of type identification (akos)
• > ACCEPTED (TypeName will be removed and TypeId stays as XRI URI.)

1. Evaluate if extension fragment type should have longer field than 4 characters.

• > If we change to more dynamic extension fragment via message definition language we probably need this for core fragments as well. Then we might want to minimize the fragment type field size. (Tommi)
• > REJECTED (if we use google protocol buffers we do not need to worry about this)

1. Evaluate whether authentication related fields need to be changed to support openid and openauth.

• > Should this be moved to later release?
• > should this not be handled by the bubble implementation instead, rather than forcing it to handle openid, leave it open? (akos)
• > We probably need some support in MXP messages. For example possibility to carry generic one time token in the mxp connection open request. This token can then be used to connect initial open id authentication carried out via web browser to the mxp connection.
• > Should we change the password/passphrase to token or secret.
• > Keep the password for basic authentication and add authentication url to join response for advanced http based authentication schemes.
• > ACCEPTED

1. Evaluate whether bubble real_time field is needed.

• > Remove bubble real time and add time field to packet header containing latest sent/resent time.
• > ACCEPTED

1. Can we correct the spelling mistake of quaranteed to guaranteed? (akos)

• > ACCEPTED

Additions and Removals of Messages

1. Evaluate whether there should be a simplified version of modification request which sends only the application specific extension instead of combination of object fragment and application specific extension. This would lower the overhead when only application specific values are being changed.

• > I think this is needed. (Tommi)
• > Yes I agree (ark)
• > ACCEPTED

1. Evaluate whether separate inject and modify messages are needed as they seem to be handled identically on implementation.

• > Can these two be combined so that modification message is removed and injection message can carry one to many object fragments of which one is the core mxp object fragment and rest are application extension fragments. (Tommi)
• > Similar change is needed to perception event message. (Perception event can occur because of inject, interact and some internal event in the object.)
• > Seems fragments handle the difference so separate messages are not needed. (ark)
• > ACCEPTED

1. Evaluate need for another message request/response pair for measuring delay and clock differences between connected parties.

• > Can this wait until someone is working on the distributed physics? (Tommi)
• > I think we should go ahead and put it in if needed so when they do work on it we don't have to revise protocol. (ark)
• > ACCEPTED (needs specification)

1. Evaluate whether collision event should be added. Collision event would contain both colliding object Ids. Collision is detected by primary bubbles of both objects. Owning participant is applying the collision to the object trajectory. If objects are in separate bubbles then collision events are sent twice. Only first one is responded to. There has to be cool down time window before reacting to new collision event.

• > I think this is immediately useful for basic demonstrations. (Tommi)
• > This could be generic interaction event. (Tommi)
• > I think this should be the generic interaction event. (ark)
• > interaction event would be fine. but are collisions always initiated by the bubble? how about very fine-grained 'touch' events, where the geometry of the participants is far from trivial? (akos)
• > ACCEPTED (create interaction request/response)

1. Evaluate whether challenge request and response should be kept in message list. When they are needed they can be added later back.

• > Remove (Tommi)
• > ACCEPTED

Implementation Considerations

Here are couple of implementation alternatives to our current approach. Should we try to specify and implement everything in MXP project or should try to rely on external dependencies in some layers? Are natively library dependencies ok? Do we require same level of specification as in MXP ?

1. Evaluate using Google protocol buffers for serialization.

• > Are language implementations compatible? (Tommi)
• > Is efficiency of google protocol buffers good enough? Create serialization with GBF of movement message and compare to size of current MXP serialization. (Tommi)
• > We could consider using GBF for MXP specific messages and keep transport layer specific ones fixed as they are. This would keep the transport layer independent of of GBF. GBF would in turn be MXP serialization layer. (Tommi)
• > is GBF the same as protocol buffers? :) otherwise, yes, protobuf is quite efficient (akos)
• > ACCEPTED (if no show stoppers appear)

1. Evalute using ENET as transport layer to lower to amount of work for each language implementation. The transport layer is probably most challenging to get working properly especially in the area of interoperation if all features like throttling are considered.

• > Can each object be assigned separate enet channel for unquaranteed signals like movement? ENET can have maximum 255 channels. This would enforce ordered dependency for unguaranteed packages. ENET drops out of order (late) arriving unguaranteed packet inside a channel. That is problematic if all movement messages use same channel: Movement messages for different objects arrive in wrong order and late arriving would be dropped. This should only happen if movement messages for same object arrive in wrong order. (Tommi)
• > ENET is native library. How challenging is it to provide prebuild binaries for different platforms and how would they be packaged? (Tommi)
• > Wrappers or native ports do not seem to exist. Can we get the wrappers or ports done as part of MXP project? (Tommi)
• > ENET seems to miss specification. Can that be seen as weakness in MXP if adopt ENET as our transport layer? (Tommi)
• > My feeling is currently that ENET might require too many compromises. All though it would provide robust alternative in short term I am confident that we can create equal quality in our own transport layer with tailored features. (Tommi)
• > enet is promissing, and has proven itself already. but the drawback is that it's native (C-only), whereas we need Java, .NET, C++, Python, etc. binding as well. Also, enet seems to lack a specification (as Tommi has pointed out), so it's probably difficult to write compatible alternative implementations. (akos)
• > REJECTED

1. If we continue working on our own transport layer, is it worth separating it and making it independent of MXP messages? We could also concentrate on modular design to be able to switch to another transport layer.

• > would make sense (akos)
• > ACCEPTED