Interreality Discussion

[vos-d] Re: s5 properties proposal

reed — Tue, 13 May 2008 16:30:00 -0400

We talked a bit on IRC but wanted to respond here too.

I think it can be summarized briefly like this, I think:

In S4, Vobjects had an ordered list of named child links to other
Vobjects, one type of which was a Property. In the proposal, Vobjects
have an unordered set of named properties, one type of which is a link
to another Vobject. (And properties can be lists or structured records,
which could include Vobject links.)

I like the benefits of embedded properties, as long as we can still
retain or mimic some of the important aspects of Vobjects as well, in
order not to limit the usefulness of properties, and also to facilitate
transmogrifying a property into a new seperate vobject (using for
example the 'overrides' part of your proposal).

I think having ordered vobjects is useful. But could live with having
ordered property data instead I guess.

Properties should still have some kind of type/tagging associated with
them (optionally) that could, for example, let programs use extensible
API to access them (like Vobjects). For example, could you do the
following using the new embedded properties:

A property of a certain type has subproperties beneath it that contain
the original value translated into other languages or locales. (or are
generally speaking alternative versions) You can ignore the
translations if you want, but if the property is tagged with
"has-translations" or whatever, and the user has a preferred language,
then use the subproperty for that language rather than the default.

You could think of various things like this where you want to have the
ability to add facets or special meaning onto a property in the same way
as you can a Vobject using a Component (metaobject).

Or, of course you might just want to have a tag on a property that might
have some meaning but which does not imply that any subproperties exist etc.

...

Can you walk through how overrides work or how one would replace an
embedded property with an override that points to a seperate vobject?
Would the new seperated property need to be a subproperty of a vobject?
Or could we have a "Property" type Vobject (like the old kind), with the
same or almost the same API as embedded properties? (And then you can
link to it directly as a child link.)

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] [[Spam?]] Tired of overpaying for meds at your local pharm store? Here is the one stop solution for yo

Tue, 13 May 2008 15:33:33 -0400

Tired of overpaying for meds at your local pharm store? Here is the one stop solution for you:

Housing the world's largest selection of items in one online store, you can purchase meds from the comfort of your home.
Hundreds of presc. meds available at just a click for all your health needs - no troublesome visits to the doc, and no exorbitant prices to pay.

Recommended by healthcare professionals and thousands of satisfied customers worldwide - visit us today.

http://shopstamps.com/img/nio/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] traits

lalo — Sun, 11 May 2008 13:20:31 -0400

http://www.iam.unibe.ch/~scg/Research/Traits/

Interesting stuff, and reminds me of s5. There may be some wisdom there
that we can reuse.

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] "Speed Racer" movie - interviews with the VFX directors

reed — Tue, 06 May 2008 11:19:33 -0400

http://www.vrmag.org/speedracer/

When they say "VR", at least in the John Gaeta interview, I think they
are really referring to panoramic images projected on the inside of a
sphere, and you view it from the center and rotate to view different
parts of the image.

The interview starts down a ways on the page. More images are further
along towards the bottom showing how they constructed some scenes.

Another interview, in video, includes some examples:

http://tv.boingboing.net/2008/05/05/speed-racer-is-popti.html

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] s5 properties proposal

Peter Amstutz — Sat, 03 May 2008 12:25:15 -0400

Why the current s5 design for "embedde children" doesn't work...

Background.

A key aspect of the design of VOS s3 and s4 is the parent/child list.
This is an associative array of name/value pairs, where the value is a
link to another vobject. This list of outgoing links plays a key role
in VOS as the primary mechanism of linking vobjects to "properties"
(other vobjects storing values that describe the first vobject) as well
as the overall organization of vobjects into a (mostly) hierarchical
namespace.

Advantages of this scheme (that have gotten us pretty far):
- A naive implementation is very easy, only need the Vobject class.
- Serialization/persistance is pretty easy.
- Introspection of the vobject structure is straightforward.
- Accomodates lists (order-sensitive) and maps (key/value pairs).
- Vobjects can share properties and link to remote properties.

Disadvantages of this scheme (that we learned the hard way):
- An efficient implementation is very difficult. Since properties are
standalone vobjects, there is a great deal of overhead associated with
it: the property vobject has its own child list, access control list,
listener list, etc.
- Because of the overhead, scaling up to large numbers of vobjects
(over 10,000) turned out to be a problem.
- The child list is always order sensitive, even when not required or
desiriable.
- Poorly suited to object/relational mapping.
- Associative array semantics permits duplicate, redundant or
conflicting entries; whether that causes problems depends on how the
child list is interpreted.
- Difficult to deal with the case where one property is dependent or
constrained by another property without exposing a race condition or
requiring additional concurrency semantics.

Original proposed solution.

Originally, the solution was to keep the basic associative array child
list, but introduce "embedded children": child properties which are
actually stored and managed by the vobject that owns them. These would
appear in the child list as normal vobjects, could be individually
linked to and/or replaced by links to remote vobjects. When doing
serialization or persistance, embedded children would be treated
specially and stored efficiently.

Advantages:
- Retains the advantages of the s3/s4 child list.
- Much less (storage) overhead than s3/s4 approach.

Disadvantages:
- Implementation is hairy. Parent vobject must juggle a bunch of
pseudo-vobjects.
- Embedded children still have some per-vobject overhead in the form of
special entries in the child list.
- Leaky abstraction. Embedded children appear to be vobjects, but most
vobject operations (such as having a child list itself) won't be
available.
- In order to save efficiently, serialization/persistance code must be
able to distinguish between embedded and non-embedded children, which
defeats the purpose of presenting a unified interface.

See the thread "s5 properties again" for discussion for a new design
that avoids these disadvantages.

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 properties again

Peter Amstutz — Sat, 03 May 2008 12:19:48 -0400

On Sat, May 03, 2008 at 09:00:30AM +0000, Lalo Martins wrote:
>
> For me this kills it. How much do you estimate it would set you back?
> And is what's wrong with the current design serious enough to justify
> this time? A good yardstick for that is: is the new design sufficiently
> better that, if you stop now to implement it, you'll still have gone as
> far by end of this year as you would if you don't?

I know, that's why I wanted to get input from everyone first.

The original reason I even got on this track was that in the process of
designing serialization and marshaling for getters and setters, I
realized the old tentative design created a number of problems I
couldn't resolve, which caused development to hit a brick wall. I
actually have a long email I wrote last week outlining the problems in
great detail, I didn't send it then but I will do so now.

> *IF* you really think it's worth it, then I'm willing to discuss the
> details; but I think before we even get to that, it would be good to
> discuss whether a project of this magnitude is worth considering at all.

Well, at the moment I'm in a bind one way or the other, since I can't
proceed without resolving this impass.

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 properties again

lalo — Sat, 03 May 2008 05:01:03 -0400

Also spracht Peter Amstutz (Thu, 01 May 2008 22:31:03 -0400):
> - It's going back to the drawing board (again) (not completely, but it
> does mean some work redesigning the VOS APIs, the XOD format, changing
> the code generator, etc)

For me this kills it. How much do you estimate it would set you back?
And is what's wrong with the current design serious enough to justify
this time? A good yardstick for that is: is the new design sufficiently
better that, if you stop now to implement it, you'll still have gone as
far by end of this year as you would if you don't?

*IF* you really think it's worth it, then I'm willing to discuss the
details; but I think before we even get to that, it would be good to
discuss whether a project of this magnitude is worth considering at all.

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] s5 properties again

Peter Amstutz — Thu, 01 May 2008 22:31:12 -0400

Some ideas for a new design for properties.

Replace the vobject "child list" with a "property map". A property is a
slot that holds some value, which can be a basic type (int, string), a
compound type (struct, array or map) or a reference to another vobject.
Reflection permits iterating over all entries in the property map.

Unlike links in the child list, the order of properties is not
significant, and two properties of the same name are not allowed. Where
order is important, data can be stored in an array property.

Paths are still available. For example:

/vos/Namespaces/core/Types/String

Where
"vos" is a vobject
"Namespaces" is a map of names to vobject references
"core" is a reference to a particular vobject
"Classes" is another map, part of "core"
"String" is a reference to another vobject

Another example:

/scene/objects/_2/position/x

Where
"scene" is a vobject
"objects" is a list of vobject references
"_2" is the reference at index 2 in the list
"position" is an xyz vector struct
"x" is the x member of the struct

At any point you can get a "directory" of properties underneath some
path, along with a reference to the VOS type.

/scene/objects/_2/position/*
would yield
"x" (/vos/Namespaces/core/Types/Float)
"y" (/vos/Namespaces/core/Types/Float)
"z" (/vos/Namespaces/core/Types/Float)

/scene/objects/_2/*
would yield
"position" (/vos/Namespaces/a3dl/Vector3)
"orientation" (/vos/Namespaces/a3dl/Vector4)
"color" (/vos/Namespaces/a3dl/Color)

And so forth.

Properties would be referenced using a vobject id + path. Properties
would be manipulated (get/set methods) by sending messages to the parent
vobject and including the path to the property of interest.

Vobjects subscribe to property changes by providing the path referring
to the property of interest.

Reflection would hold additional metadata describing properties, such as
which properties should be automatically stored for serialization and
persistance.

Vobject references would support both "hard" links (link to a specific
vobject id) and "soft" links (where there is a relative path that must
be resolved to determine the actual vobject).

In addition to "embedded" properties (those which are part of the state,
which are always there) the user would be able to attach their own
"override" properties.

An override property would be either an entirely new property, or
replace an existing embedded property. Matching an override would be
path based, for example:

addOverride("/object/position/x", 22)

Would change the "x" component of the position to 22. Any read or write
to "x" or "position" would use the override, rather than the underlying
value. Removing the override would restore the old value.

The override could provide a slot to store the value, it could tie the
get/set operations to some other property of the same type (referenced
as a vobject + path), or it could tie the get/set operations to some
other methods a vobject.

Advantages of this approach:
- This makes the vobject model is much closer to the most common idea
of objects as "methods" + "properties".

- A purely dynamic implementation is easy using maps and lists.

- A static implementation (where the underlying properties are
zero-memory-overhead) is straightforward using code generation.

- Serialization, peristance, synchronization and replication are easier
since purely declarative data (state) is distinct from the imperative
methods that manipulate it.

Disadvantages:
- It "isn't VOS" since it discards the last trappings of the s4 vobject
model

- It's going back to the drawing board (again) (not completely, but it
does mean some work redesigning the VOS APIs, the XOD format, changing
the code generator, etc)

Thoughts?

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Recommendations needed for cool new technologies!

Mon, 28 Apr 2008 21:39:28 -0400

(And also)

I just saw it on CNN.com:
Student 'Twitters' his way out of
Egyptian jail
http://www.cnn.com/2008/TECH/04/25/twitter.buck/index.html

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Recommendations needed for cool new technologies!

Mon, 28 Apr 2008 21:28:02 -0400

Recommendations needed for cool new technologies!

Hi all-

I'm looking for ideas for 'what's new in technology'
meant to introduce cool or free new stuff that may have
some bearing. Please send anything interesting that
you've come across to me. It doesn't have to be VOS-
related necessarily - anything new and interesting
on the web or pertaining to digital media could fit.

Just to give you an idea of some stuff covered last
time, the main items were:

"Turn your computer into a TV."
https://www.getmiro.com/about/what-is-miro.php

Send FREE messages to any Mobile Phone** No charge
for sending. Receiver may incur charges depending on
their carrier and plan.
http://gizmosms.com/
http://www.text4free.net/

openid:
http://openid.net/

Scribd is trying to be the youtube for documents
where anyone can upload PDFs, Word docs, etc. They
have created an alternative to the PDF format called
iPaper which loads faster than a PDF and has some
security features that PDF doesn't (e.g. you can't
download the documents).

http://www.scribd.com/ipaper

This is Flash demo that shows a page-turning effect
when you click the pages:

http://www.rubenswieringa.com/code/as3/flex/Book/

Here's another example of a page-turning effect:

http://www.openlibrary.org/details/intlepisode00jamearch

pretty cool sounding project to build a highly
scalable document storage system:

http://incubator.apache.org/couchdb/

Cheap multi-touchscreen and digital whiteboard
(and 3d viewer):
http://www.ted.com/index.php/talks/view/id/245

1) The Sophie Project is an open-source multi-media
alternative to PDF for books.

Here's a short paper describing why an alternative
to HTML and PDF is needed for electronic books:

http://www.scribd.com/doc/33485/Introduction-to-Sophie

Here are a few Quicktime videos of what an early
version of Sophie looks like:

http://www.futureofthebook.org/sophie/files/Making_a_Sophie_Book.mov

http://www.futureofthebook.org/sophie/files/sophie_beethoven_demo.mov

And here's the main site:

http://www.sophieproject.org/

Ted Nelson, the inventor of the term "hypertext",
gave a presentation about "transclusion" or how
to include one document within another:

http://video.google.com/videoplay?docid=-8329031368429444452

Here are some visualization resources that the
publishers might be interested in:

* There are sites where you can upload a data set and
various visualization are generated and displayed:

http://services.alphaworks.ibm.com/manyeyes/home

http://www.data360.org/index.aspx

http://www.swivel.com/

Here's a short article about it:

http://radar.oreilly.com/archives/2007/01/ibm-wants-many-eyes-on-visuali.html

There's a free program called "Processing" which
you can use to create visualizations. Here's a
gallery of images:

http://processing.org/exhibition/index.html

Here's a nice chart showing different visualizations
(roll your mouse over the squares).

http://www.visual-literacy.org/periodic_table/periodic_table.html

- Jason

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 vobject properties

reed — Fri, 25 Apr 2008 08:48:52 -0400

I'm worried about introducing yet more complexity into S5. You know that this is
a big concern of mine.

What is the exact overhead for having entries in the child list for embedded
properties? You need a contextual name, and you need the object. The list
itself stores the position value. The EmbeddedProperty object stored in the
Component could implement the "child list entry" interface and store its own
contextual name (which would be constant for each kind of embedded property),
so the only overhead would be the pointer to the EmbeddedProperty object in
the list. This is greater than zero, so it wouldn't be "zero overhead", but
it would let you treat properties and children in the nice and flexible way,
and it's only a pointer's worth of overhead. Or it could be an index into
something else instead of a native pointer and we could cap it at 32 bits
or whatever if you're really trying to shave bits off there.

Reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 vobject properties

Peter Amstutz — Thu, 24 Apr 2008 23:20:38 -0400

On Thu, Apr 24, 2008 at 11:39:01AM -0400, Reed Hedges wrote:
>
> Properties as child vobjects is too useful to get rid of I think. If
> properties are always embedded, then you can't have two vobjects share
> a property, which is one of the most important features of VOS. They
> also can't be remote for whatever reason, and you can't use the normal
> Vobject/Metaobject/Component stuff to create a specialized kind of
> property. These are also critical features.
>
> I'm still not clear on why properties as some kind of embedded
> children won't work. Can you give an example? Yes, the parent object
> has to keep track of which children are embedded and which aren't, and
> there's overhead there, but it shouldn't be that big of a deal,
> especially since in most cases they will be a small bounded set of
> known properties (not a huge list). You would have to have some proxy
> fake vobject to give to the site/host for remote objects to contact,
> of course, but is that also too much? What I liked about your
> embedded-properties comprimise is that it ought to let one switch a
> property from embedded to non-embedded transparently. And it's one
> less extra thing for applications/tools to interact with -- another
> great thing about VOS we should preserve (small number of basic
> operations for apps and programmers to worry about.)

The gist of the problem is that my goal for "embedded children" was
ideally that there would be zero overhead. For example if you have a 32
bit integer property, the underlying storage (in the C++ class or
whatever) ought to only require exactly one 32 bit integer -- four
bytes. The parent vobject handles messages to/from the embedded
property, and synthesizes a stand-in pseudo-vobject on demand if the
embedded property needed to be accessed independently. In other words,
rather than having an entry in the child list specifically for the
embedded property (which is redundant, if you have 100,000 instances of
that vobject type, you need to have that child entry repeated 100,000
times), accessing the property is handled through reflection and code
generation.

Unfortunately this approach raises a number of design questions that I'm
not entirely happy with.

1) The whole point is for embedded children show up in the child list.
If the embedded children doesn't have a position assigned to it (zero
overhead, remember) then what position does it show up at?

2) If there are multiple components, what is the best way to
merge or concatinate the embedded children lists?

3) What is the least supprising behavior when a user tries to remove,
replace, or reorder an embedded child entry?

4) What vobject identifier is assigned to the embedded child? Is it
based on the parent vobject id, or should it be assigned entirely
independently?

5) Ideally when serializing a vobject, embedded properties should be
stored as efficiently as possible. In addition, my thinking was that
embedded properties would correspond to database columns in a future
object/relational mapping scheme. If embedded properties are treated
like vobjects, that likely adds a layer of complexity beyond just
storing data.

Now, I'm not saying this design can't be made to work. However, the
most obvious solution means adding special "embedded child" entries to
the child list of every vobject of a particular type. Meaning, if an
vobject type is used 100,000 times, there are 100,000 child list entries
which are mostly redundant, but have to be there just in case...

> Basically, we just need another layer in the type hierarchy, in a
> sense. You have basic Vobject-like things that sites/hosts (not sure
> which) can deliver messages to and which can send messages, and which
> have URLs and can be linked to by Vobjects. Below that are Real
> Vobjects and Embedded Properties. Embedded properties are deficient or
> special-case Vobject-like things in that they are simply missing type
> extensibility and children and other features that real Vobjects have.
> They can be very simple C++ objects just holding their data buffer, or
> perhaps just a reference to their "owner" vobjects which hold their
> data for them, if that is more efficient.

I see. You're thinking of the s4 design where properties == vobjects,
therefore s5 embedded properties == lightweight vobjects. That's true,
to some extent, but the goals were also to have zero (memory) overhead
beyond the storage space for the actual data, and to have a more
straightforward data model of vobject state so that serialization and
persistance can be implemented efficiently.

So my concern is that the old vobject child list model may be the best
way to achive to these goals, so it is at least worth examining the
issues and alternatives before plowing ahead with a complicated
compromise solution.

On alternative I am considering would be to change the child list from
an associative array to a property map. Entries in the map could be
either embedded properties or dynamic properties, but since it would be
a map there wouldn't be any ordering issues. Ordered lists (necessary
for applications like hypervos) would still be possible, but would
stored as properties (so you would have a property would be a list of
outgoing links.)

In this scheme one could share the same value among multiple properties
could be acomplished by "overriding" the embedded property with a
dynamic property linking to the shared value.

This idea is still a little half baked, so I will follow up with
examples when I have nailed the design down a bit more.

[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 vobject properties

reed — Thu, 24 Apr 2008 12:24:28 -0400

In other words, I sort of imagined it like this:

class Entity
{
handleMessage();
set parents;
string url;
}

class Link
{
string cname;
int pos;
Entity *child;
Entity *parent;
}

class Vobject : Entity
{
list children;
vector embeddedProperties;
list components;
etc.
}

class PropertyCore
{
read();
write();
dataBuffer;
etc.
}

class EmbeddedProperty : Entity, PropertyCore
{
Vobject *owner;
}

class PropertyVobject : Component, PropertyCore
{
}

class Site {
set entities;
}

So if a host or site has entities foo, bar, baz, you can send messages to
vip://site/foo, vip://site/bar, vip://site/baz, and they could be vobjects or
embedded properties. An "Entity" is basically "something that can be linked to
and can receive messages", so it includes both embedded and non-embedded
objects.

I know this is simplified but does this make sense?

Reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 vobject properties

reed — Thu, 24 Apr 2008 11:39:15 -0400

Properties as child vobjects is too useful to get rid of I think. If
properties are always embedded, then you can't have two vobjects share a
property, which is one of the most important features of VOS. They also can't
be remote for whatever reason, and you can't use the normal
Vobject/Metaobject/Component stuff to create a specialized kind of property. These
are also critical features.

I'm still not clear on why properties as some kind of embedded children won't
work. Can you give an example? Yes, the parent object has to keep track of
which children are embedded and which aren't, and there's overhead there, but it
shouldn't be that big of a deal, especially since in most cases they will be a
small bounded set of known properties (not a huge list). You would have to have
some proxy fake vobject to give to the site/host for remote objects to contact,
of course, but is that also too much? What I liked about your embedded-properties
comprimise is that it ought to let one switch a property from embedded to
non-embedded transparently. And it's one less extra thing for
applications/tools to interact with -- another great thing about VOS we should
preserve (small number of basic operations for apps and programmers to worry about.)

> Do
> the fields have a fixed position in the list?

?

> What happens when someone
> tries to insert a link in the child list between embedded child entries?

Then their positions change... not sure I see the problem... The
ParentChildRelation (or whatever its called now) just points to the embedded
property that happens to be inside its owner Vobject object, rather than a stand
alone Vobject object. Still has a name, position, and the parent vobject can
just treat it the same way as the other members of its child list when it comes
to ordering and iterating and finding children etc.

> Or tries to replace an embedded child? Or remove it?

Similar to a normal vobject. The Vobject that owns is still responsible for it
and does all work associated with it if some other Vobject has a child link to
it. Otherwise, deletes it.

I guess Vobjects would also need messages to ask them to create new embedded properties
as well, so you could recreate the embedded property.

>
> * In order to not have to distinguish between an embedded vobject and a
> real one, they need to use the same identification scheme. Which means
> there needs to be a way to assign or synthesize an identifier which can
> be used to identify the embedded child uniquely from the parent.

This should be possible, no? The vobject can basically contain Property objects
which are capable of handling remote message same as stand alone properties, and
give those to the site/host to keep in its list. So it gets a unique
identifier, is that hard for some reason?

(Or rather than a normal Property, could be a special EmbeddedProperty type that implements the same interface as stand
alone vobjects for receiving messages, etc.)

Basically, we just need another layer in the type hierarchy, in a sense. You
have basic Vobject-like things that sites/hosts (not sure which) can deliver messages
to and which can send messages, and which have URLs and can be linked to by
Vobjects. Below that are Real Vobjects and Embedded
Properties. Embedded properties are deficient or special-case Vobject-like
things in that they are simply missing
type extensibility and children and other features that real Vobjects have. They
can be very simple C++ objects just holding their data buffer, or perhaps just
a reference to their "owner" vobjects which hold their data for them, if that is
more efficient.

But maybe I'm missing some of the issues here...

Reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] s5 vobject properties

Peter Amstutz — Wed, 23 Apr 2008 00:54:26 -0400

Things have been quiet lately, but I assure you, we are still working!

Anyway, something I've been mulling over --

One of the planned changes in the design of s5 as compared to s4 is the
integration of plain-old-data properties as part of the vobject class
definition. In s3 and s4, property data (simple stuff like integers,
strings, position vectors, etc) is stored by special vobjects with a
special "property" type. This has some nice advantages in that the
properties describing a vobject are just child links to other vobjects,
so browsing and editing vobject structures is very straightforward.

The disadvantage of this scheme is that it is very inefficient. It
results in vast amounts of overhead for storing what amounts to a field
in a data structure, and it also introduces coordination issues among
property vobjects that should otherwise be logically tied closely
together. It would be much better (more memory efficient among other
things) to be able to store simple data as part of the vobject class
directly.

So, for s5, the idea I originally had was to try and meet these goals
halfway and have "embedded children". These would be sort of "virtual
vobjects" (hah) that would appear to be child vobjects, but be managed
entirely by the parent vobject they are embedded in. This would combine
the benefits of the "everything is a vobject" abstraction with the
advantages of storing things more efficiently.

As always, though, the devil is in the details:

* For the "embedded child" concept to work (or even make sense), these
"virtual vobject" property fields need to show up in the child list. Do
the fields have a fixed position in the list? What happens when someone
tries to insert a link in the child list between embedded child entries?
Or tries to replace an embedded child? Or remove it?

* In order to not have to distinguish between an embedded vobject and a
real one, they need to use the same identification scheme. Which means
there needs to be a way to assign or synthesize an identifier which can
be used to identify the embedded child uniquely from the parent.

* What happens when a vobject of the same name and same "property" type
is added to the child list? Is it added to the list (resulting in two
fields that seemingly mean the same thing) or is the value assigned to
the existing embedded child?

I have ideas about how to deal with these various issues, but generally
they involve adding additional management data around the embedded
children. Unfortunately, that would be somewhat self-defeating, since
the original goal was avoid having any storage overhead and work with
just the bare field of the parent class.

Because it is so ambigious what the best (or even correct) semantics are
for vobject properties as embedded children, I wonder if it is best just
to drop the idea entirely. Another idea I have been mulling over is for
vobjects to have an unordered bag of properties. This would primarily
be embedded fields manipulated via reflection, but probably also allow
new properties to be added on the fly. In this scheme, properties could
include parent/child links or lists of links, which would likely mean
there wouldn't need to be a single child list -- although actually, the
set of properties would be used in a similar fashion to the s4 child
list, without the strict ordering constraint.

Overall, such a change would align the general VOS data/object model
much more closely to that of mainstream object-oriented programming
languages (particularly Python, C#) than it has previously. In
particular, the child list in s4 was designed with XML in mind, where
preserving ordering in tree structures is important.

Thoughts? To a large extent the "a vobject is a list of links to other
vobjects" concept is pretty fundamental to s3 and s4 VOS. On the other
hand, I've come to the conclusion that it makes an efficient
implementation very difficult, so it is worth considering other ideas.

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 site ids

Peter Amstutz — Thu, 10 Apr 2008 12:17:39 -0400

On Fri, Apr 04, 2008 at 01:46:46AM +0000, Lalo Martins wrote:
> Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +0000):
> > Sorry to resurrect this, but after working with s5 for two months, I
> > still have the same concerns, only more so :-)
>
> Actually, never mind; I had an epiphany ;-)
>
> Here's basically how it works...
>
> My VOS browser is looking at a remote site, and finds an object of a type
> it doesn't know. Now, for some reason, it wants to introspect this
> object (maybe to build a python wrapper?). What can it do?
>
> Well, it just asks the remote host to send over a replica of the site
> containing that class. My local replica won't be considered
> "authoritative", since the host don't have the private key, but then
> again the remote host doesn't either -- library sites are "ghost" sites,
> that no host has the private key for.
>
> Now, this could easily be done by treating Library objects specially, and
> putting in place a system to replicate them. But why make special cases,
> when there's already a perfectly good system to replicate sites?

Yes, that's exactly how it is intended to work. That's why limiting
access to the private key (signing power) is important to the integrity
of the system. It allows you to receive data from third parties on
behalf of the source site with some assurance that the data has not been
tampered with. Similar to how Bittorrent works, for example.

Keep in mind we're only talking about the APIs, not the actual
implementation, so it makes sense that your code should bind to a
specific version of the API that was written against. Obviously you
can't make changes to an API without also changing the client code that
uses it. As a third party, if you want to change a class definition,
you have the option of extending an existing class to define a class on
a site you control.

As for managing changes to existing classes, I have been meaning to add
a per-class version number system that can be used to determine
forwards/backwards compatability. Something along the lines of
major.minor.revision, where

* different major versions are incompatible (v1 and v2 classes can't
interporate at all)
* different minor version are backwards compatible (eg v1.4 can access
an object of v1.2, but not the other way aorund)
* different revisions are forwards and backwards compatible (v1.4.5 and
v1.4.10 are interchangable)

This would be separate from the notion of site of global revisions at
the site level.

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 site ids

lalo — Thu, 03 Apr 2008 21:47:13 -0400

Also spracht Lalo Martins (Thu, 03 Apr 2008 13:40:51 +0000):
> Sorry to resurrect this, but after working with s5 for two months, I
> still have the same concerns, only more so :-)

Actually, never mind; I had an epiphany ;-)

Here's basically how it works...

My VOS browser is looking at a remote site, and finds an object of a type
it doesn't know. Now, for some reason, it wants to introspect this
object (maybe to build a python wrapper?). What can it do?

Well, it just asks the remote host to send over a replica of the site
containing that class. My local replica won't be considered
"authoritative", since the host don't have the private key, but then
again the remote host doesn't either -- library sites are "ghost" sites,
that no host has the private key for.

Now, this could easily be done by treating Library objects specially, and
putting in place a system to replicate them. But why make special cases,
when there's already a perfectly good system to replicate sites?

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] More on the web site

reed — Thu, 03 Apr 2008 15:45:55 -0400

I've started putting together a new website in (s4) hypervos at
http://interreality.org:4088/home.

It's simplified from the current site, and has less info. As we update things
like documentation for S5 and make releases, we can expand the site. I make a
wiki page (DraftDocs) that links to some of the random notes and drafts that are
in the wiki, and also links to the old Creating Interreality manual for people
that want more info.

Any comments?

I still have to:

* Improve the screenshots, either make new ones from the first S5 app
prototype, or get some old ones
* Improve the colors a bit
* Make a new background image
* Tweak and improve the layout and whitespace. It looks ok on my screen but
will try a few others.
* Make some "compatibity" pages from the old site that get some google
referrers
* Add a few more icons and illustrative figures.

Reed

--
http://interreality.org/~reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: s5 site ids

lalo — Thu, 03 Apr 2008 09:41:21 -0400

Sorry to resurrect this, but after working with s5 for two months, I
still have the same concerns, only more so :-)

Also spracht Lalo Martins (Tue, 12 Feb 2008 04:55:19 +0000):
> Also spracht Peter Amstutz (Mon, 11 Feb 2008 17:43:45 -0500):
>> With regard to shipping the private key, my thinking is that publishing
>> an API is like specifying a protocol, and that you really want a way of
>> unambigiously referring to a specific API as published by a specific
>> entity at a specific version.
>
> Hmm... no, I don't think I for one want that. It would mean I can't
> make changes to third-party library from source A and still have
> third-party software from source B work against it without a manual
> hack-and- recompile. That would be against the spirit of Free Software,
> and the letter of the LGPLv3 (which I see you picked for s5 and I
> approve of).
>
> Yes, it would be nice to have a way of *referring* to a specific (...)
> as you say. But having all code by default *depend* on a specific
> version published by a specific entity? Bad idea, IMO.
>
> For the matter, I don't think Libraries should be distributed as a site,
> at all. I think they should just import the Library object into the
> local host (possibly inside some "safe" location like /otd or /libraries
> or even /lib). But it seems you have put some thought behind this
> decision; would you mind sharing your reasoning with us?

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Wiki editing fixed

reed — Mon, 24 Mar 2008 09:01:53 -0400

I fixed the wiki permissions so that anyone who is logged in should be able to
edit pages. Click the "login" link at the top. If you don't have a login yet,
follow the instructions, though it's a bit strange. You have to go to
UserPreferences, fill in the form (enter your password twice, ignore the
confusing label).

Let me know if there are any problems.

There is a seperate group that has permission to delete and revert pages. If
you need a page deleted or want that permission let me know.

Reed

--
http://interreality.org/~reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Choosing a GUI toolkit for S5

reed — Sun, 23 Mar 2008 11:25:52 -0400

Well, I've been reading the docs for Qt4 and experimenting with the
example programs they provide, and I'm leaning towards it as a toolkit.

Does anyone have any input on choosing a toolkit?

* Qt4 looks nice, even in Gnome-- much better than Qt3 did
* It has some nice built in widgets and features that we can use, like
dockable panes that can be dragged around, etc.
* It has some good 2d graphics drawing features
* Trolltech is more actively/quickly working on improving it and
adding new features and supporting all platforms
* It has an embedded web browser widget (using WebKit) that's both
easy to use and complete
* It has good support for some mobile platforms and they're actively
working on that
* QtDesigner is freely available, and is a pretty good design tool, in
my very brief experience with it. It could be a nice option for rapidly
developing new type-specific GUI components.

I still hate qmake. But maybe we can find or write some code for scons
that replaces it (runs the MOC code generator, localization tool, etc.)

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Fun with the generator

lalo — Tue, 18 Mar 2008 20:01:27 -0400

Also spracht Peter Amstutz (Tue, 18 Mar 2008 11:09:24 -0400):
> On Mon, Mar 17, 2008 at 07:33:24PM +0000, Lalo Martins wrote:
>> Well. I spun off the web MVC stuff into a new library (hypervos).
>> That opened a pandora box of generator fun :-)
>
> Yea, as you've probably figured out by now, writing good C++ is hard,
> but automatically generating good C++ is even harder.

:-D

>> 2: The #define guards use only the file name. If you have headers with
>> the same name in different libraries (eg MVC.hh)... you get my point I
>> think. I manually changed them to eg #define _hypervos_MVC_hh_, might
>> make the change in the generator later.
>
> Oops. Yes, the generator should be smarter than that. See my comment
> below about directory organization for headers.

Fixed in my branch (assuming we agree _hypervos_MVC_hh_ is good enough).

>> 3: Much worse happens if you have namespaces with the same name :-) the
>> generated code has things like MVC::View all over, which of course
>> generate "ambiguous namespace reference" errors galore.
>
> This is a bit of a pathalogical case, although hopefully now you see the
> reason for the site_xxx namespace.
>
> The brute force solution would be to have the generator go ahead and
> qualify everything with the excessively long site_xxx namespace, which I
> was trying to avoid purely for the sake of readability.

Ah no, you're taking it a step further. I'm referring to VOS Namespace
objects, not C++ namespaces in general. See, you already solved this
problem ;-) since we encourage each library to ship one Library object,
named the same as the library, and then a number of Namespace objects
inside it. Splitting a (VOS) Library in different (C++) libraries and/or
directories would, yes, be a problem, but we'll cross that bridge when
there is even water on the river ;-)

What I'm talking about is...
- Site 0011223344556677889900aabbccddee
- Library vos
- Namespace MVC
- Site 6879706572766f73203474656877696e
- Library hypervos
- Namespace MVC

See? So that could be handled in C++ (and it's how I solved it by
manually editing the files, but that means I can't atm run the generator
on mod_vos or my other project) by qualifying it with vos::MVC:: or
hypervos::MVC::

>> 4: This is unrelated to the hypervos move, I noticed it earlier. If my
>> class "Foo" extends "vos::core::Bar", then Foo.hh will have #include
>> "Bar.hh"
>> which of course won't work so well... should be :-)
>
> Since I was originally focused on getting the libvos core to work, I
> didn't give too much thought to how the C++ headers should be explictly
> organized into directories. Again, the brute force solution would be to
> have the headers mimic the namespace up to and including the site, which
> would be horribly verbose but would eliminate most of the ambigious
> cases.

Again, you're forgetting we already have the handy Library object, which
I'd like to encourage developers to keep unique-ish. So
would do it (and, bonus of bonuses, already works with our current
layout!), and it's what I made the generator do, in my branch.

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Fun with the generator

Peter Amstutz — Tue, 18 Mar 2008 11:09:33 -0400

On Mon, Mar 17, 2008 at 07:33:24PM +0000, Lalo Martins wrote:
> Well. I spun off the web MVC stuff into a new library (hypervos). That
> opened a pandora box of generator fun :-)

Yea, as you've probably figured out by now, writing good C++ is hard, but
automatically generating good C++ is even harder.

> Also, I'm not saying these need to be fixed urgently; just that we need
> to know about them for the future.

I'm not surprised by any of these limitations you ran in to, I've been
planning on fixing them when it became a real problem.

> 1: mod_vos.xod (and my other projects) extend a lot of classes from the
> new library. But since the generator doesn't know about those, it
> reports broken links and generally doesn't know what to do.
>
> The answer to this may be in my plugin loader; I might try my hand at
> solving it later this week.

At the moment, external libraries can successfully import from the main
VOS namespace because it is available in the generator by virtue of being
compiled into libvos. However, it should be able to import from other
libraries in general. A stopgap solution would be to add an option to the
to generator pre-load additional XOD files.

Eventually we should have a general set of strategies for searching for
site replicas (local repositories, going on line, possibly extracting them
from executables) so finding and importing an interface library will be no
different from accessing and replicating any other vobject site (be it a
3d world, hypervos, etc).

I do like the idea of using the plugin loader to ask a binary library what
its interface is.

> 2: The #define guards use only the file name. If you have headers with
> the same name in different libraries (eg MVC.hh)... you get my point I
> think. I manually changed them to eg #define _hypervos_MVC_hh_, might
> make the change in the generator later.

Oops. Yes, the generator should be smarter than that. See my comment
below about directory organization for headers.

> 3: Much worse happens if you have namespaces with the same name :-) the
> generated code has things like MVC::View all over, which of course
> generate "ambiguous namespace reference" errors galore.

This is a bit of a pathalogical case, although hopefully now you see the
reason for the site_xxx namespace.

The brute force solution would be to have the generator go ahead and
qualify everything with the excessively long site_xxx namespace, which I
was trying to avoid purely for the sake of readability.

> 4: This is unrelated to the hypervos move, I noticed it earlier. If my
> class "Foo" extends "vos::core::Bar", then Foo.hh will have
> #include "Bar.hh"
> which of course won't work so well... should be :-)

Since I was originally focused on getting the libvos core to work, I
didn't give too much thought to how the C++ headers should be explictly
organized into directories. Again, the brute force solution would be to
have the headers mimic the namespace up to and including the site, which
would be horribly verbose but would eliminate most of the ambigious cases.

> 5: Just to put in a positive note and because I like the number 5 better
> than 4, I'll say I found great joy in recent s5 work; in particular
> Vobject::clone() saved me hours of toil!

That's good to hear :-) I slipped that one in as part of the template
stuff I did (which you should take a look at, by the way.)

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Fun with the generator

lalo — Tue, 18 Mar 2008 09:19:32 -0400

Also spracht Lalo Martins (Mon, 17 Mar 2008 19:33:24 +0000):
> 1: mod_vos.xod (and my other projects) extend a lot of classes from the
> new library. But since the generator doesn't know about those, it
> reports broken links and generally doesn't know what to do.
>
> The answer to this may be in my plugin loader; I might try my hand at
> solving it later this week.
>
> 2: The #define guards use only the file name. If you have headers with
> the same name in different libraries (eg MVC.hh)... you get my point I
> think. I manually changed them to eg #define _hypervos_MVC_hh_, might
> make the change in the generator later.
>
> 3: Much worse happens if you have namespaces with the same name :-) the
> generated code has things like MVC::View all over, which of course
> generate "ambiguous namespace reference" errors galore.
>
> 4: This is unrelated to the hypervos move, I noticed it earlier. If my
> class "Foo" extends "vos::core::Bar", then Foo.hh will have #include
> "Bar.hh"
> which of course won't work so well... should be :-)
>
> 5: Just to put in a positive note and because I like the number 5 better
> than 4, I'll say I found great joy in recent s5 work; in particular
> Vobject::clone() saved me hours of toil!

Fixed 2 and 4 today, may tackle 1 or 3 tomorrow.

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Fun with the generator

lalo — Mon, 17 Mar 2008 15:33:57 -0400

Well. I spun off the web MVC stuff into a new library (hypervos). That
opened a pandora box of generator fun :-)

I'm a bit exhausted, so I'll go over them briefly; if you need more
detail, ask, and I'll elaborate tomorrow. Or check out my branch and
play around yourself.

Also, I'm not saying these need to be fixed urgently; just that we need
to know about them for the future.

1: mod_vos.xod (and my other projects) extend a lot of classes from the
new library. But since the generator doesn't know about those, it
reports broken links and generally doesn't know what to do.

The answer to this may be in my plugin loader; I might try my hand at
solving it later this week.

2: The #define guards use only the file name. If you have headers with
the same name in different libraries (eg MVC.hh)... you get my point I
think. I manually changed them to eg #define _hypervos_MVC_hh_, might
make the change in the generator later.

3: Much worse happens if you have namespaces with the same name :-) the
generated code has things like MVC::View all over, which of course
generate "ambiguous namespace reference" errors galore.

4: This is unrelated to the hypervos move, I noticed it earlier. If my
class "Foo" extends "vos::core::Bar", then Foo.hh will have
#include "Bar.hh"
which of course won't work so well... should be :-)

5: Just to put in a positive note and because I like the number 5 better
than 4, I'll say I found great joy in recent s5 work; in particular
Vobject::clone() saved me hours of toil!

best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Choosing a GUI toolkit for S5

reed — Mon, 10 Mar 2008 20:02:31 -0400

Braden McDaniel wrote:
>> http://interreality.org/wiki/ChoosingAGUIToolkit
>
> GTK+'s licence is LGPL, not GPL.
>
> Also, GTK+ can interact with OpenGL via GtkGLExt.
>
> Also, with regard to the language issue, Gtkmm is worth pointing out.
> Gtkmm is a very high quality modern C++-aware C++ wrapper for GTK+.
>

Thanks, fixed.

Reed

--
http://interreality.org/~reed

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: Choosing a GUI toolkit for S5

Sun, 09 Mar 2008 15:12:27 -0400

On Sun, 2008-03-09 at 12:55 -0400, reed wrote:
> Posted at: http://interreality.org/phorum/read.php?2,222,222#msg-222
> reed wrote:
>
> To help choose a GUI toolkit to use for the S5 user interface app, I made this comparison chart. wxWidgets and Qt are the top contenders, though I added a few others to consider.
>
> If you have any corrections or know any of the missing pieces of data ("unk"), please correct it on the wiki or reply here.
>
> http://interreality.org/wiki/ChoosingAGUIToolkit

GTK+'s licence is LGPL, not GPL.

Also, GTK+ can interact with OpenGL via GtkGLExt.

Also, with regard to the language issue, Gtkmm is worth pointing out.
Gtkmm is a very high quality modern C++-aware C++ wrapper for GTK+.

--
Braden McDaniel e-mail:
Jabber:

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Choosing a GUI toolkit for S5

reed — Sun, 09 Mar 2008 12:55:37 -0400

To help choose a GUI toolkit to use for the S5 user interface app, I made this comparison chart. wxWidgets and Qt are the top contenders, though I added a few others to consider.

If you have any corrections or know any of the missing pieces of data ("unk"), please correct it on the wiki or reply here.

Comparison chart here: http://interreality.org/wiki/ChoosingAGUIToolkit

Reed

[vos-d] serialization

Peter Amstutz — Tue, 04 Mar 2008 11:19:08 -0500

My current task is working on a serialization framework for structs and Vobjects. This will
handle loading and saving state for vobjects, and provide the basis on which to implement
marshaling and persistance. Being able to load and save structs will also make it possible to
start working on some of the upper layers of the VOS stack, such as A3DL (which needs to be able
to efficiently represent data like vertex arrays.) I have worked out an efficient template-based
approach which supports arbitrary serialization/deserialization methods, so we can easily have
binary, XML, YAML, JSON etc serializers, and message encoding for VOS network protocols will
probably be built on the serialization framework as well.

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

[vos-d] Re: More new S5 classes/concepts

Peter Amstutz — Tue, 04 Mar 2008 09:55:21 -0500

On Mon, Mar 03, 2008 at 05:27:46PM -0500, Reed Hedges wrote:

> I was under the impression that, for the most part, you are always going
> to be working through Wrapper objects. Is this true?

The ultimate purpose of the wrappers is support marshaling for cross-language and
cross-host method calls. Since C++ doesn't have a built in interception facility, you have to
insert some stub code in between the caller and the target. One way to do this would be remote
objects like we had in s4, but that doesn't handle the cross-language/cross-thread cases very
well. Instead, s5 has very lightweight wrappers which manage access to the underlying object.

So yes, in normal code you almost always want to be working through the wrapper classes, since
they make everything else work (marshaling, reference counting, promises).

I'm willing to entertain naming schemes other than "-Wrapper", I just don't want it to be the
stem name for the simple reason that due to the semantics of C++ it would be ambigious whether
you are working with a smart pointer or a copy of the actual object. Possible alternatives:

VobjectWrapper
VobjectHandle
VobjectStub
VobjectPtr
VobjectRef

--
[ Peter Amstutz ][ tetron@interreality.org ][peter.amstutz@tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d