Re: [vos-d] Project: Zephan

2008-07-30 Thread Peter Amstutz
Congratulations!

On Wed, Jul 30, 2008 at 11:51:27AM -0400, Reed Hedges wrote:
 
 
 I have a new top priority project that must compete with VOS -- Zephan 
 Isaac was born on Friday at 7:30 PM!  Though so far he's been great and 
 we're well rested (so far) and on top of the world.
 
 More photos and news will be on my web site and on flickr in the 
 upcoming weeks.
 
 Reed
 
 
 -- 
 http://interreality.org/~reed


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


-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] getting back on track

2008-07-02 Thread Peter Amstutz
I just wanted to mention that I have recently started taking the  
train to work instead of driving.  This gives me about 45 minutes  
each way of reliable, uninterrupted time to do a bit of hacking, so I  
will finally be able to get back on track working on VOS after a  
couple months of coding drought.  Since my laptop is a MacBook Pro,  
the first order of business will probably be to get the voss5 branch  
to work on OS X.  The commuter rail also offers a 802.11 to cellular  
bridge so I even have Internet access!

There are still some outstanding design issues I am mulling over,  
once I have resolved the immediate issues with my development  
environment, we'll have to restart the conversation on design and  
strategy.

[ Peter Amstutz ][ [EMAIL PROTECTED] ] 
[EMAIL PROTECTED]
[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


Re: [vos-d] s5 properties again

2008-05-03 Thread Peter Amstutz
On Sat, May 03, 2008 at 09:00:30AM +, 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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] s5 properties proposal

2008-05-03 Thread Peter Amstutz
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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] s5 properties again

2008-05-01 Thread Peter Amstutz
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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]


signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 vobject properties

2008-04-24 Thread Peter Amstutz
 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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


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

2008-03-04 Thread Peter Amstutz
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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] serialization

2008-03-04 Thread Peter Amstutz
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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] templates/macros

2008-03-03 Thread Peter Amstutz
I went ahead and did it already, actually.  I needed the template functionality 
in the core so 
that I could specify VOS classes that are logically templates, such as 
UInt8DynamicArrayProperty 
(which is a property holding an array of bytes).  Without a template feature, I 
would have to do 
a lot of cut and paste to get DynamicStringArrayProperty, 
DynamicVector3ArrayProperty, etc...

The current scheme is somewhat incomplete though, we will need listeners to be 
able to properly 
propagate changes in the base template to all the template instances.

On Sat, Mar 01, 2008 at 02:14:00PM -0500, Reed Hedges wrote:
 Peter Amstutz wrote:
 
  The idea is to set up Template vobjects which have TemplateParameters 
  which are stand-ins for links other objects and are substituted when you 
  actually create a template instance.  The TemplateInstance vobject 
  links to the template and some set of parameters, and will have an 
  instantiate method on it which produces a vobject structure with the 
  appropriate parameter substitution.
 
 
 This is definitely something we need.  It ought to be very 
 straightforward to implement as a component type, using listeners.
 
 But let's not add any more tasks like this right now, let's get the VOS 
 core working first (including listeners)
 
 Reed
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Website design ideas

2008-02-18 Thread Peter Amstutz
Wow.  Very impressed.  Reminds me how much web design is really not my 
thing.

I would say I like the color/styling/background of #1 but the more 
column-oriented layout of #2.

On Sun, Feb 17, 2008 at 08:06:50PM -0500, Reed Hedges wrote:
 
 Here are two ideas I had for a new website design.  Both are rough sketches.
 
 1. http://interreality.org/~reed/tmp/iro/index.html
 
 2. http://interreality.org/~reed/tmp/iro/index2.html
 
 
 Thoughts, ideas?
 
 
 Reed
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] templates/macros

2008-02-18 Thread Peter Amstutz
Here's a quick brain dump of something I'm working on.  The specific 
goal is deal with the problem of parameterized types.  In this example, 
I show how one might define UInt8DynamicArrayProperty as a Property 
holding a DynamicArray of UInt8.

The idea is to set up Template vobjects which have TemplateParameters 
which are stand-ins for links other objects and are substituted when you 
actually create a template instance.  The TemplateInstance vobject 
links to the template and some set of parameters, and will have an 
instantiate method on it which produces a vobject structure with the 
appropriate parameter substitution.

Nothing coded yet, so this will likely change.  Incidentally, this is 
actually fairly similar to the template system coded for the original 
hypervos (which runs parts of interreality.org) so this idea of 
generalized subtree substitution is likely to be useful beyond the 
specific problem I'm trying to solve.

vobject name=Property type=/vos/core/Template
  vobject name=produces linkTo=/vos/core/Class /

  vobject name=propertyType type=/vos/core/TemplateParameter /

  child name=extends type=/vos/core/Component /

  vobject name=value type=/vos/core/Member
child name=param linkTo=../../propertyType /
  /vobject
/vobject

vobject name=DynamicArrayProperty type=/vos/core/Template
  child name=extendsTemplate linkTo=/vos/core/Property /

  vobject name=memberType type=/vos/core/TemplateParameter /

  vobject name=propertyType type=/vos/core/DynamicArray
child name=memberType linkTo=../../memberType /
  /vobject

  vobject name=size type=/vos/core/Member
child name=type linkTo=/vos/core/UInt32 /
property name=readOnly 
type=/vos/core/BooleanPropertytrue/property
  /vobject

  vobject name=getSlice type=/vos/core/Method
vobject name=formalParameters type=/vos/core/Struct
  vobject name=start type=/vos/core/Member
child name=type linkTo=/vos/core/UInt32 /
  /vobject
  vobject name=length type=/vos/core/Member
child name=type linkTo=/vos/core/UInt32 /
  /vobject
/vobject
child name=returnType linkTo=../../../propertyType /
  /vobject
/vobject

vobject name=UInt8Property type=/vos/core/TemplateInstance
  child name=template linkTo=/vos/core/Property /
  child name=propertyType linkTo=/vos/core/UInt8 /
/vobject

vobject name=UInt8DynamicArrayProperty 
type=/vos/core/TemplateInstance
  child name=template linkTo=/vos/core/DynamicArrayProperty /
  child name=memberType linkTo=/vos/core/UInt8 /
/vobject


-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 site ids

2008-02-12 Thread Peter Amstutz
You've got it.  Setting up aliases based on prefix at the top of the XOD 
file was exactly the solution I had in mind to the verbose-site-ids 
problem.  Similarly in the code generator we just need to emit a macro 
which hides the scary site namespace.

On Tue, Feb 12, 2008 at 06:04:50PM -0500, Reed Hedges wrote:
 
 
 In VOS it in fact would be easy to build a little tree of the types with 
 different names to make them easier for people to work with, while 
 keeping their real names hidden.
 
 So you can make an object like /t and select out the specific top 
 level versions used from the containers (namespaces?) with the big ids.
 
 E.g.
 
 /t/vos - /vos:0011223344556677889900aabbccddee/vos
...Has various children for core types...
 /t/a3dl - /vos:0011223344556677889900aabbccddef/a3dl
...Has various children for 3d types...
 /t/mytypes - /vos:992288337744beffc38aa3712cdd219a8e/mytypes
...Has various children for custom types...
 
 /foo type=/t/mytypes/foo
 /bar type=/t/a3dl/object3d
 
 Maybe we even enshrine a container like /t or /_types as standard place 
 to put the working set of types, as a convention that all user 
 interfaces use, and so when they are telling a user what the type of a 
 vobject is, they can just strip off the prefix, or when preseting the 
 user with a list of possible types, just provide a listing (or tree 
 view) of the children of /t, etc.
 
 Or a UI can just look at the type definition to get a user friendly type 
 name.
 
 But OK, in the general case, we need to come up with ways like this to 
 help users navigate vobjects, whether in a particular application or in 
 VOS stuff like this, without having to put a lot of special stuff in the 
 user interface clients.
 
 Reed

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 site ids

2008-02-11 Thread Peter Amstutz
On Sat, Feb 09, 2008 at 01:02:15AM +, Lalo Martins wrote:
 Yet, you didn't address my actual point ;-)
 
 I know what site IDs are supposed to be for.  My question is -- do we 
 really want libraries to ship as a separate site each?  I realise the 
 key space is pretty large, so polluting it is probably no big deal, but 
 I see no big advantage in this case.  (You would need to ship the private 
 key, anyway, right?)

In VOS terms, a Library is a set of interfaces, not concrete classes.  
This is why the Implementation objects are separate from the Class 
objects.  This idea needs to be developed more, though, since even 
within the VOS type system itself I have found it useful to have both 
abstract classes (that cannot be instantiated ever, interface only) and 
concrete classes.

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.  If you let everybody have the private key 
then you cannot guarantee that, because anyone could produce a signed 
API document.  One of the foundation concepts in s5 is that ownership 
of a private key implies the ability (and responsibility) to coordinate 
changes to that site so that you don't have conflicting replicas 
floating around from different sources.

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 site ids

2008-02-08 Thread Peter Amstutz
On Fri, Feb 08, 2008 at 09:52:40AM +, Lalo Martins wrote:
 Is there any rhyme or reason to site ids?

The current testing site ids are not true site ids.  The site id is 
actually supposed to be the public half of a public/private key pair 
using elliptic curve cryptography.  A 128 bit key yields about 64 bits 
of security.

 If all libraries will ship a separate site (as XOD or something) with 
 their OTDs, won't that pollute the site id space?

 And aren't them bound to clash at some point?  Maybe set up a registry of 
 library site ids somewhere in the website?

The idea is for site ids to be globally unique, since there is only a 
1/2^128 chance of generating a collision.  In order to claim to be a 
site you have to prove that you know the corresponding private key, thus 
you can't just pick an aribtrary public site id (unless you know how to 
work backwards to get the private key, in which case the NSA would like 
to have a word with you.)
 
 Or is this (library OTD) going to be substantially different later on?

I understand your confusion, it isn't very meaningful at the moment 
because it is not yet doing any of the digital signature checking that I 
have planned.

I need to write a tool that spits out public/private keypairs for use 
with VOS.

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


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

2008-01-30 Thread Peter Amstutz
On Mon, Jan 28, 2008 at 03:28:57PM +, Lalo Martins wrote:
 Also spracht Peter Amstutz (Sun, 27 Jan 2008 23:38:04 -0500):
  (lots of clarifications on s5 concepts/classes)
 
 On that note... can we have a documenting property (akin to Python's 
 docstrings and __doc__)?  Preferably with nice syntax sugar on XOD :-)  
 Just having all the information you have on this post, right there on the 
 XOD file (and presumably the C++ generated from it) would have helped 
 immensely.

There's a description property which is pretty much what you're asking 
for, it can be attached to most elements (classes, methods, members, 
etc) and is intended to be used for output to code comments and to code 
documentation tools.

With regards to syntactic sugar, the current XOD format is intended to 
be very low level data structure dump.  What I would like to do is use 
XSLT or a macro language to define translations from a friendlier syntax 
(which can include all sort of helpful tags) to a low level 
representation such as XOD.

 Also... I can't make heads or tails of interreality3d :-( could we have a 
 very minimal hello world?

Ask and ye shall receive.  Take a look at voss5/src/app/helloworld.

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


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

2008-01-27 Thread Peter Amstutz
 context.

In the interreality3d app, the TreeView can view any VOS data type 
(since displays the vobject children) and requires a wxWindowContext.  
It creates a view object which then actually adds the necessary 
wxWidgets controls to the supplied wxWindow to display the tree view.

 What does it mean to append children to the local host?  I am guessing 
 this is so the object doesn't get destroyed (by reference count/garbage 
 collection), and so you can also obtain it by name later?  Do all 

The local host is a special site.  Sites now have a root child list 
which is like a root directory.

 objects need to be added to the local host (like they were all children
 of the local site in s4)? And if so, why not do that automatically when 
 created?

When created, vobjects must be associated with some site (such as the 
local host).  The intention is that in order for the vobject to be 
persistant, it must be connected to the vobject structure so there is a 
path from the root to the vobject.  Vobjects which are not connected to 
the root are not persistent.

 Can you explain more these changes to A3DL? What is a scene, what is a 
 render layer, clock, node, etc.?

I'm in the process of redesigning A3DL based on my experience with 
several mature scene graph APIs (Gamebryo, Open Scene Graph and 
Lightfeather.)  The new A3DL design is pretty preliminary and not 
actually implemented at all.  I'll go over it when I've actually put a 
bit more work into it and there is some code that actually does 
something.

-- 
[ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] MVC

2007-12-10 Thread Peter Amstutz
Lalo and I talked about this briefly on IRC.  In think the central idea 
is simply to have a repository (the factory in the document) where you 
can go and say, I would like to view this object X, with display type 
Y and get back a list of possible candidate vobject implementations 
that can view or control the model vobject.  The view type or 
display type could be a text terminal, 2D GUI, 3D environment, web 
page, etc.  This is a generalized notion of some of the ideas I was 
exploring in the Interreality 3D prototype, with Lalo's interest in 
specifically applying it to web apps.

Personally I think this makes a lot of sense, and is likely something 
that should be part of the core APIs.

On Mon, Dec 10, 2007 at 10:28:36AM -0500, Reed Hedges wrote:
 
 Thanks for writing up your thoughts.  How important do you think it is 
 to define specific interfaces for MVC?
 
 One thing I started doing for S4 was a library called vos toolbox 
 that as a set of tools, mostly in the form of listener classes and 
 metaobject classes, that can be used to translate events from one 
 group of vobjects into actions applied to another - i.e. they could be 
 used as building blocks in implementing MVC controllers.  There are a 
 few checked in to the s4 repository (some that do math or reformat 
 property values), and I have more ideas listed at 
 http://interreality.org/wiki/ApplicationVosToolbox
 
 Reed

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 progress and design

2007-12-06 Thread Peter Amstutz
On Thu, Dec 06, 2007 at 11:11:31AM +0100, Karsten Otto wrote:

 Ok, I see. But this implies there could be more servers than just  
 one, each hosting a replica. Which one do I contact for updates? With  
 VOP/VIP URLs this was straightforward, but please remind me again,  
 how do I contact a vos:0011223344... key-based site? Is there a name  
 server somewhere?

There's one additional complication, which is that there are sites and 
there are hosts.  A host is a special kind of site which is never 
replicated and represents a single process/single instance of a server.  
The goal being that a site can be clustered across multiple hosts.  So a 
site is bound to one or more hosts, and connections are made between 
hosts rather than between sites.  This provides a layer of abstraction 
between the concrete concept of a site (an actual OS process on a 
physical computer) and the virtual concept of a site which is replicated 
many places.

Ownership of a site simply means knowing the private key.  If you know 
the private key, you are able to issue properly signed documents that 
describe the state of (and state changes to) the site.

To answer your question, yes, this requires some way of mapping 
identifiers to network addresses.  My original idea was that the site 
issues a signed document listing one or more hosts ids that are 
authorized for that site, and the host issues a signed document listing 
one or more network addresses it can be contacted at.  That contact 
information is propagated through friend-of-a-friend introductions, so 
that if some site tells you to contact another site, it can also provide 
the contact information.  Other name resolution methods (DNS/MDNS, 
distributed hash tables, central metaserver on interreality.org, or ???) 
would also be a good idea.  Unlike DNS, spoofing replies is much more 
difficult, since the replies have to be signed to coorrespond with the 
same public id you are trying to resolve.

For the separate matter of mapping human-readable names to site ids, I 
don't have an answer to that.  That's sort of a sticky problem because 
such a system should be hardened against all sorts of abuse (spamming, 
domain squatters, etc) many of which are social and not technical.  I'm 
imagine there's been some interesting research into this area, though, 
which would be worth looking in to.

 Uh, okay... so... The site in this document is just a namespace,  
 which makes sense given the new idea of a site being some abstract  
 thing manifested only by lots of replicas. I.e. when I use the type  
 vos:00112233/OTD/vos/FooClass I am using a replica of the abstract  
 type definition.
 
 I was confused since I still though of a site as something you  
 could connect to with Ter'angreal or mesh, while the new kind does  
 not necessarily have any actual servers hosting the replicas.
 
 ... Right?

You've got it.  The idea is to move towards content-oriented addressing 
rather than location-based addressing, at least at the granularity of a 
site.  Of course, for interactive sessions, you maintain a session to an 
actual server which is the actual site, so that you can exchange updates 
in real time (for walking around in a 3D world or whatever).

 Ok, so the average user will never be concerned with MyTypeImpl, but  
 only ever interacts with MyTypeWrapper? In this case I agree with  
 reed to drop the Wrapper part and just call the thing MyType.

The average user is concerned with MyTypeImpl if they are implementing 
new components, which I would hope to be a common operation (as common 
as adding new classes to any object oriented application).  The user 
also needs to supply the correct implementation when instantiating a new 
vobject, since if there are (for example) two implementations of 
IOutputStream, you need to select which one you actually want.  In terms 
of actually calling methods on it, it is isolated from the user via the 
wrapper class, for implementation reasons I discussed previously.

I'm still mulling it over.  It does make the client code easier to read, 
but at the expense of potentially introducing confusion between the 
wrapper classes and real classes, which have very very different 
semantics.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 progress and design

2007-12-06 Thread Peter Amstutz
 on the assumtion that  
 there are more of them. I.e. if i want to access a remote Java  
 object, I only need its MyType interface and an remote object  
 reference. If I want to *create* a new remote object, I have to  
 design the MyType interface for the users, and create an MyTypeImpl  
 with the actual functionality. There is a hidden third class, a  
 MyTypeStub, which is usually autogenerated, and which handles the  
 marshalling for remote (or local!) invocations - this is what users  
 handle, though they are never aware of it, only of the fact that they  
 got a MyType object to use.
 So, how is this didfferent from what VOS s5 is supposed to do?

In your example, MyTypeWrapper in VOS is roughly equivalent to the 
marshalling stub.  The difference is that (and correct me if I am wrong 
on this) the semantics of CORBA and Java RMI are that on local objects 
method invocations are made directly and executed in the same thread, 
and on remote objects method invocations are synchronous, blocking 
calls.  In VOS, my intention is for all method invocations to be 
asynchronous, nonblocking calls, including calls between different 
threads in the same process.  As a result, *all* objects in the system 
need that stub harness, even if the common case (invocations in the same 
process, in the same thread) still just pass through to the underlying 
concrete implementation.

Because you're calling between threads on a shared memory system, it 
doesn't make sense to create heavy remote stubs that are managed by 
the framework for objects which already exist in process.  Wrappers are 
not managed by the framework but are instead lightweight stack objects 
that can decide whether to marshal (or not) the method call based on the 
circumstances.

My concern is that if the wrapper class is named with just the name 
stem, the following situation is very confusing:

{
  Vobject* foo = getFoo();
  delete foo;
  // Oops.  I think I deleted foo, but all I did was delete
  // the wrapper.  The underlying object is actually still there.
}

{
  VobjectWrapper* foo;
  delete foo;
  // I know it is a wrapper, so I know I'm just deleting the wrapper
  // and that the underlying object is untouched.
}

This is a little contrived, since wrappers are usually stack-allocated 
(although the confusion is still there, just not as obvious), but 
similar cases can be made for other common operations such as assignment 
and comparison.

It's ugly, but it should be considered an artifact of the 
implementation.  Languages with better metaprogramming facilities (meta 
object protocols, in the traditional academic sense) and hopefully 
script language bindings should not require this technique.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 progress and design

2007-12-05 Thread Peter Amstutz
On Wed, Dec 05, 2007 at 11:34:45AM -0500, Reed Hedges wrote:
 
 We should also include at this point a reminder of why there's a code 
 generator.
 
 If I understand things correctly, the goal is to use the code generator to 
 (a) generate code for different programming languages
 (b) make it easier for users to generate MetaObject (now called 
 Component) wrapper classes corresponding to different type interfaces 
 (and in different programming languages).
 
 The fact that Peter happened to use the code generator to generate VOS 
 itself is, again if I understand it correctly, partly for (a), and 
 partly to make sure it works well.
 
 Correct me if I'm wrong Pete.

You're on the right track, but there's more to it than that.

It provides a set of formal semantics for VOS which are defined 
externally of a particular programming language.  With the spec in hand, 
you only have to write a code generator (or other metaprogramming layer) 
and run it against the spec to map VOS onto a new target language.

It gives a self-contained type system, so when two programming languages 
talk about a VOS Class, they are unambigously referring to the same 
thing.  It also encourages developing an OS- and language-independent 
vobject-based standard library of APIs and components instead of 
dropping down to the language-specific standard library for common 
tasks.  For example, I've already added InputStream and OutputStream 
classes as part of VOS in order to read and write files.  This means you 
will be able to read from or write to streams which come from other 
language runtimes, processes, or hosts.

In the case of the C++ binding, the code generator will automate 
marshalling, unmarshalling, and pipling, which would be tedious and 
error prone to write by hand (and changes often during development).  
C++ template metaprogramming doesn't really help here, since templates 
don't provide the reflection features to be able to say for each method 
in this class...

Finally, the code generator also keeps some other miscellaneous 
boilerplate code in sync, such as registering classes and 
implementations, and embedded the correct copy of the interface spec in 
the executable so that reflection is available at runtime.

Rather than simply being a convenient tool, the VOS object model is 
almost a new language that happens to be hosted on C++.  I actually hope 
to see VOS implemented in other languages (and not just through foreign 
function interfaces) and think it will be a better fit for higher-level 
languages that already provide garbage collection, reflection, 
marshaling, promises, continuations, etc.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 progress and design

2007-12-05 Thread Peter Amstutz
On Wed, Dec 05, 2007 at 11:43:47AM +0100, Karsten Otto wrote:
 Hi Peter, some questions/comments from the top of my head:
 
 What does importReplica() imply exactly? Is this just loading a local  
 copy, or does it include contactig the remote site and merging updates?

The idea is this is actually a copy of (a subset) of the site at some 
revision.  You're loading from this copy, which might have been 
retrieved from the server, or maybe from somewhere else.  After loading 
the replica, you might contact the server to find out if anything has 
changed between the revision you have and the most recent revision.  It 
is heavily inspired by distributed version control, although the focus 
is more on disseminating signed updates from a central site than on 
branching and merging.

 The property lookup example seems a bit verbose for a task that I  
 assume will be quite frequent... Wouldn't this be wrapped into some  
 MetaObject method getOccurrence() : String?

Yes, that's exactly what it does.  The code generator provides those 
accessors.

 The interface description seems to slowly approach WSDL Land... Have  
 you considered some shorthand syntax to free a developer of all the  
 XML clutter? Or do you envision GUI-based development tools for this  
 (really the only way to live with WSDL if you have to use it)?

I agree.  It's not high on my own list of priorities, but this would be 
a good, easy project if someone wants to help out. (hint, hint)

 The fact that you need a *site* for an interface description seems  
 pretty strange to me, even though I am aware you are re-using the XOD  
 stuff for this... but do developers really have to generate a siteID  
 key for every interface they design? Rather pointless, isn't it?  
 While it may make sense to actually have the OTD vobject structure  
 linked on a site that uses it, you usually don't know the target site 
 (s) at development time. Maybe modify the XOD parser to consider the  
 site/siteID optional, or use a shorthand syntax in the first place :-)

That's because the site is actually part of the logical namespace.  What 
this means is (site id shortened for brevity):

  vos:00112233/OTD/vos/FooClass 
is entirely different from
  vos:44556677/OTD/vos/FooClass

Because the class vobject itself is a different vobject located on a 
different site.  This means an object that implements the first 
FooClass is not necessarily compatible with the second FooClass.

Another way of thinking of it is that the act of defining and making 
available the interface definition is the same as publishing any other 
type of data via VOS.

 What exactly is the site revision? An interface version in this case?  
 What does this mean on a real site, i.e. virtual world? Does it  
 change with every child addition/removal, or even every nested  
 property value change? If so, what is the datatype, and what to do  
 when it wraps?

The exact sematics of revision control still need to be decided, but 
generally speaking, every discrete change would increment the revision.  
The datatype will be a 64-bit long integer, so we don't need to worry 
about it overflowing in our lifetimes :-)

 Regarding naming, there seem to be MyType, MyTypeWrapper,  
 MyTypeImpl... what exactly is the difference between the three? The  
 old distinction Interface, RemoteType, LocalType does not quite seem  
 to fit anymore in the way you use the new code.

Well, s4 never really had a concept of abstract interface except for the 
Vobject class, but it is a standard pure-virtual interface-oriented base 
class.

LocalType, being the concrete implementation of a component 
(metaobject type), is most closely related to MyTypeImpl.

RemoteType is most closely related to MyTypeWrapper (since the 
wrapper will handle marshaling and unmarshaling).  Wrappers are 
different since they are (a) a very lightweight temporary stack-oriented 
class, not mananged by VOS and (b) the wrapper manages access to all 
vobjects, whether local or remote (since marshalling is also required to 
call between threads).  I've come to the conclusion that allowing 
customized stand-ins for remote objects is a bad thing, in general.  It 
should be handled at the application level.

A large part of the change in terminology is due to an overall change in 
thinking.  The idea is to not differentiate between local and remote 
objects per se, but have objects than I can change and objects I need 
to talk to someone else to change.  Hence the notion of our local copy 
of such objects being a replica, and if we know our local copy is up 
to date (by checking revisions) then it is trivial to service read 
requests using the local copy.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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

Re: [vos-d] s/MetaObject/Component

2007-11-29 Thread Peter Amstutz
On Thu, Nov 29, 2007 at 01:33:22PM +0100, Karsten Otto wrote:

  Also metaobject is
  an existing term of art in the programming language community  
  having to
  do with defining and manipulating the semantics of how programming
  language objects are invoked, and while this is something that will
  exist in VOS, the current MetaObject class isn't it.
 
 Ok, I heared that term before, but am not quite sure what it means an  
 certainly don't use it in day-to-day programming (maybe I'm just old- 
 fashioned).

http://c2.com/cgi/wiki?MetaObjectProtocol

It's not something people use in day-to-day programming (unless your job 
involves Common Lisp or Smalltalk) but it is an entrenched term in the 
object-oriented community, so I prefer to avoid the confusion.

 I understand your desire to avoid a clash of terms, but I don't think  
 Component is a good replacement; in fact it may make things worse!   
 If you absolutely have to rename it, I'd rather see one of the other  
 fuzzy terms like Facet, Aspect, ...

Well, Aspect implies (to me) aspect-oriented programming.  Facet is 
a possibility, although I've mainly encountered that in the capability 
security community where it has a little bit different connotation (as a 
possibly-restricted view or handle that mediates access to some 
underlying object).

The most common use of term component is probably in the context of 
COM, XPCOM, KParts and so forth type of systems where it simply implies 
loosely-coupled objects, with separatation of interface and 
implementation and often dynamicly loadable and language-neutral.  The 
plan is for S5 VOS vobject MetaObjects to do all those things, hence 
changing the name to component.

On a side note, I have been meaning to sit down and do a writeup on s5 
development progress, which will hopefully clarify things a bit.  While 
for several months I was working part time to be able to devote time to 
VOS, I am presently working full time again for financial reasons, so 
VOS development is squeezed -- even writing email.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s/MetaObject/Component

2007-11-29 Thread Peter Amstutz
Part is even more generic/vague than component, I think.  Subparts 
might be slightly better.  Another way to look at it, which would be 
clearest:

vobject-getParts();
vobject-getSubparts();
vobject-getFacets();
vobject-getRoles();
vobject-getTypes(); // very bad, the term type is already overloaded
vobject-getFragments();
vobject-getTraits();
vobject-getComponents();

Fragment was another term I was mulling over, although that implies to 
me something that is broken or incomplete.

I still prefer component, since to me implies a nice, well defined 
piece that is designed to plug into a bigger system.

I should also point out that if we were to interface COM with VOS, it 
would most likely be in the form of mapping VOS (MetaObject) APIs to COM 
APIs...  The similarities are more than superficial (which makes sense, 
since some of the goals of VOS overlap with the goals of COM/DCOM).

On Thu, Nov 29, 2007 at 10:37:37AM -0500, Reed Hedges wrote:
 
 Component is generic, and also recalls COM etc.
 
 How about:
 
 Part
 Facet
 Role
 Type
 Fragment
 Trait
 
 What exactly *is* a metaobject?  It's a constituent Vobject that's part of a
 real Vobject, and which implements a facet or part of that Vobject, probably
 corresponding to a type.  It implements part of the Vobject's interface. It
 provides an interface to the programmer (e.g. in C++ or whatever) for that 
 facet or part or type.  It handles a set or group of messages within that 
 Vobject. 
 
 I kind of like Part. Could even be inside Vobject's namespace I guess
 (Vobject::Part).  I don't know how much this might have changed in s5 but
 generally a programmer only needs to know about MetaObjects when he is
 implementing one, if you're just using VOS you deal either with objects as
 generic Vobjects or with their type interface classes (e.g. Property, 
 Object3D,
 etc.)
 
 
 Reed
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] thinking about a new web site

2007-10-23 Thread Peter Amstutz
On Tue, Oct 23, 2007 at 02:09:11PM +0200, hellekin wrote:
 On Mon [EMAIL PROTECTED]:58:07 -0400, Peter Amstutz wrote:
  
  Anybody want to help do a new site design?
 
 *** I can give a hand on the new version.

Great!

As I wrote in the previous email, I think want to keep more or less the 
same set of sections, but do a new layout for the overall page template.  
So feel free to create a new style sheet, menu, header/footer layout, 
background, logo and so forth.  Put up a sample page and link to it on 
vos-d and everyone can comment on it.  How does that sound?

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] S5 and ordering listeners

2007-10-22 Thread Peter Amstutz
On Mon, Oct 22, 2007 at 04:39:39PM -0400, Reed Hedges wrote:
 
 Can you comment on this Peter?
 
 Let's say I want a set of listeners attached to an object to be 
 invoked in order. Let's say that both listeners live on the same local 
 site (process) and maybe are both associated with the same vobject.  
 Will there be a way to do this in S5? What if the listeners are 
 associated with metaobject types (e.g. a vobject L is linked to 
 another vobject Source. Applying type X to L causes listener x to be 
 created, and applying type Y casues listener y to be created, each 
 listening to vobject Source (they find Source because it's linked to 
 L). I always want x to be notified before y of any changes to Source.
 
 Does this make sense?

I don't really follow, no.  Could you give an example?

The plan for listeners is for it to be based properly on message passing 
between objects, rather than straight callbacks.  Once messages are sent 
out, there isn't really a guarantee on ordering, so if you need a strong 
cause and effect trigger, you should probably have an intermediate 
object that subscribes to the primary object, does some work, and then 
passes it on to the next listener...

Or are you trying to do some kind of filtering?

I can't answer the questions without knowing what you're trying to 
acomplish.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] thinking about a new web site

2007-10-22 Thread Peter Amstutz
On Mon, Oct 22, 2007 at 07:56:09PM -0400, Reed Hedges wrote:
 
 Here are some ideas I had on revamping the web site.
 
 Graphic Design
 --
 
 * Change the background to white or another light color. Maybe change 
 the main content area to a different shade too, rather than current grey.
 
 * A set of background/side illustrations, that convey some of the more 
 general themes of VOS and Interreality -- interconected things; 
 multifaceted stuff; distributed structures -- but also look cool and 
 have a computer graphics style to them.

Sure.  I did the current design a few years ago based on an even older 
design of yours (still online at http://interreality.sourceforge.net/ 
!!!)  (we should probably take down the sourceforce page, although it is 
of historical interest ;-)

Anyway, I don't claim to be a competent graphic designer, and the 
interreality.org cascading style sheet has grown completely out of 
control, so it is probably time to start over from scratch from a design 
standpoint.

Anybody want to help do a new site design?

 Pages
 -
 
 It's great that the site runs on hypervos. Maybe we want to keep it, or 
 maybe we want to switch to something else then go back to it.  It would 
 be great to have text in Vobjects that can be reused on multiple pages. 

Having updated the pages, I think it's worth staying with HyperVOS for 
now.  We'll want to transition to an s5-based system eventually, but we 
need s5 first.

 If we use a wiki for the main pages, we'd need to hide all the meta wiki 
 stuff.

I've seen quite a few projects that use a more or less straight up wiki 
for their whole site, take http://bazaar-vcs.org/ for example.  Hiding 
the wiki links does look more polished, though.

 Sections
 
 
 I don't think we really need a hierarchy [with the exception of About, 
 see below], at least for the public facing aspect.  These links can be 
 listen in a little table or grid at the top of the page, like they are 
 now (but set in a grid so they line up nicely, perhaps with logical 
 groping/separation).
 
 * About [See below]
 * Screenshots
 * News [redirects to forum announcements]
 * Download
 * Docs
 
 * Forums
 * Mailing Lists
 * IRC
 * Servers [not at first, but eventually link to running servers]
 
 * Bugz
 * Contact

That's pretty much what it is divided up into right now, minus a 
contact page, and no servers page since there are none.

 About Section/Docs
 --

My main concern is that so much stuff is changing, in terms of both 
overall goals (trying to be a more focused on addressing specific tasks) 
and in the specifics of the technology, its hard to write useful 
documentation until development has settled down a bit.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] notes from IRC, pt 2

2007-10-22 Thread Peter Amstutz
Additional notes on interreality3d gui from IRC.
Participants: mm765, tetron

 - Had trouble moving the avatar.  Determined that this probably 
stemmed from a combination of issues:
   - Initially tried to use WASD keys (typical first person shooter 
configuration).  Interreality3D 0.1 doesn't bind these keys to movement.
   - The d key goes into drag and drop mode, which overrides the 
movement keys and is not obvious how to escape from (you hit escape).
   - Once figured out arrow keys for movement, reported stuttering 
movement.  This seemed to be tied to resizing the window (?).  Mentioned 
he was using Windows Vista -- interreality3d hasn't been tested first 
hand on Vista, so it may be an issue with that OS.

 - Reported crash when clicking on ? button, then closing the help 
panel.

 - Did not like having to push escape to cancel out of minor modes.  
Should at least be able to cancel mode using the same key that got into 
the mode.

 - Did not think splitting was a common enough operation to support 
having those buttons on the button bar.

 - Mentioned running out of space in the window when using the mouse to 
move.

 - Liked the ability to go back to previous views.

 - Suggested having view templates for set GUI configurations.  I 
mentioned and we agreed this is the same idea as UI skins discussed 
previously on vos-d.

 - Suggested that chat view should be integrated as an overlay on the 3D 
view; a suggestion also put forward by winterk (I believe.)

 - Did not like Emacs-style multi-key chords.  I pointed out that the 
majority of Ctrl- and Alt- prefix key shortcuts are already monopolized 
by the OS, other GUI controls or by convention, so there are very few 
shortcut keys available without getting into multi-key chords.

 - Agreed the the UI will probably become clearer once its purpose is 
clearer.  Lacking the ability to do any interesting browsing or editing 
(which depends on the backend to supply that data) it requires a bit of 
imagination to see what the workflow will be like, and how a 
configurable UI plays into that.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]


signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] notes from IRC

2007-10-19 Thread Peter Amstutz
Notes from some initial discussion of the interreality 3d interface.
Participants:  winterk, zaharazod, tetron

- Should be more like stuff people expect
  - Splitting and merging panels is likely to confuse casual 
users

- Casual users should not have to mess around with the interface 
(splitting, creating new panels, changing modes, etc)
  - Suggested having a basic layout and an advanced layout to help 
casual users
  - Discussed implementing different layouts as UI skins which set up 
a particular panel/mode configuration for a particular task (browsing, 
editing, programming, etc).  Skins could hide customization buttons like 
splitting.

- Mentioned that even in a virtual worlds like Second Life where 
building is emphasized, the majority of users don't want to create, just 
use other people's prefab stuff.
  - But still important to make build tools accessable to ensure that 
curious users can get into it easily.

- Suggested adding right-click context menus to 3D mode (good idea).

- Suggested initial 3D panel after login should include chat panel 
(good idea).

- Discussed different input schemes for controlling avatar movement.
  - Suggested that first person shooter WASD + mouselook is most 
immersive
  - Drawback is that it requires grabbing the mouse, which is 
incompatible with other user interface modes such as editing, where you 
want to stay in one place and grab and move things around with the 
pointer.

- Discussed that the goal is for UI controls to be per-world 
configurable
  - The idea is that when you join a world, you download a bundle of 
scripts and key/mouse bindings which provide a customized the user 
interface to that world.
  - So the issue of what 3D controls to use is primarily an issue of 
preference or what makes sense for a particular application, and not one 
of policy
  - Key and mouse bindings could be reconfigurable by the end user.

I think this idea of reconfiguring the UI for different worlds also fits 
nicely with the idea of beginning/advanced/task-specific UIs discussed 
at the top.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] notes from IRC

2007-10-19 Thread Peter Amstutz
On Fri, Oct 19, 2007 at 05:40:40PM -0400, Reed Hedges wrote:

 I agree, this is something I suggested to Pete earlier. Do people want this
 feature added to the prototype, or wait for the real app?

Well, the intention is for the prototype code to morph into the real 
application frontend, so work on it won't go to waste.  It's called a 
prototype largely because the all-important network backend is a mockup, 
so it looks pretty but doesn't do the most important things the real app 
will do.

So if this is something you'd like to work on, I encourage it.  However, 
if the goal is to get something useful in peoples hands sooner, I think 
I should focus on identifying a minimal set of backend VOS functionality 
for version 0.2, implementing that, and porting the UI prototype to use 
the real backend.

 This is something that will make it really useful and work well, but 
 is pretty novel AFAIK. I don't really know of any other application 
 that does this, except that Javascript has a key handler so web pages 
 can get keystrokes (except control keys).  VRML does it similarly I 
 guess.  But those are all used by the content, neither of those is 
 customizing the shape of the meta-UI.

By comparison with the web, arguably the splitters are kind of like the 
much-hated web frames.  It's worth considering why people hate frames so 
much, and make sure we avoid those mistakes.

Also, I really want to support a floating heads up display (HUD) 
overlayed on the 3D view.  My idea is to have some kind of vector 
graphics representation (based on SVG, probably) that can be used to 
describe floating HUD elements/UI controls.  This actually would be 
quite useful independent of a HUD.  It would be able to render to 
texture so you can interact with GUI elements in-world, and could be 
used for rendering generic embedded cross-platform 2D UIs (what people 
are trying to do with web apps these days).  If we develop a really good 
2D UI kit, we could throw out wxWidgets and just use our own 
vector-based UI :-) But I'm getting ahead of myself.

 So we need to think through how it works.  E.g. should it 
 automatically reconfigure, then show a message at the top notifying 
 you that it did? Or should it ask first? Should it only allow 
 configuration within the one pane that is viewing the Vobject that 
 wants to reconfigure?  Should it open a new window frame with the new 
 configuration, leaving your old configuration alone?

Hmm, well a multi-panel configuration is a bit different from a minor 
mode, which only affects a single panel of a specific mode.  I'm not 
sure how to group it, although at the level of the entire frame would 
make the most sense.  When you join a world, it could pop up a dialog 
saying, this would would like to set a custom UI, is that ok?  As you 
mentioned, we'll have standard UI configurations that people can use as 
defaults or to build from to create their UIs.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] interreality 3d 0.1 released

2007-10-19 Thread Peter Amstutz
The first prototype of next generation s5 development branch of VOS
has been released.  This is a user interface prototype, intended to
demonstrate progress, solicit feedback and get bug reports.

Interreality 3D is supported on Windows, OS X (intel) and Linux.
Download it here:

http://interreality.org/download


A few notes:
 - This is a prototype.  It lacks major functionality, in particular it
lacks any sort of networking backend.  The purpose is to demonstrate
user interface ideas.

 - Please sends us your comments, concerns and ideas, either to the
vos-d mailing list, or on the web at the vos-d discussion board at:
http://interreality.org/phorum/

 - If you find a crash, please file it with Bugzilla:
http://interreality.org/bugzilla/

I hope you find this prototype interesting, and it is a sign of much
more development to come!

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] bugzilla

2007-10-18 Thread Peter Amstutz
Pending the release of the interreality 3d 0.1 user interface prototype 
(that's a mouthful) I have set up bugzilla for bug tracking and feature 
requests.  It's accessable on the main page and at 
http://interreality.org/bugzilla

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] cross-platform packaging

2007-09-25 Thread Peter Amstutz
Just found this program to manage generating cross-platform (well, cross-Unix) 
packages.  It takes its own package spec file and can generate native packages 
for a whole bunch of unix platforms, including deb and rpm.

http://www.easysw.com/epm/

It supports OS X (?) but ideally we want to distribute the entire app as a 
single app bundle.  Windows, as usual, is its own case.  I'm planning on using 
Windows Installer XML (Wix) to generate Microsoft installer (.msi) packages.

I'm still tinkering with the UI prototype (my current project is to add back 
and forward buttons to views enabling browser-style navigation) but I want to 
put it to bed soon so we can start working on concrete functionality in the 
backend.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] progress and planning

2007-09-25 Thread Peter Amstutz
The mailing list has gone quiet again, but that doesn't mean nothing is 
happening.  I am presently working on the new UI prototype for VOS, which is 
shaping up quite nicely.  The general plan going forward is:

a) Finish the UI prototype.  This has taken longer than I expected due to a 
combination of technical issues and having implemented a lot more ideas than I 
had originally.  I'm hoping to be done with this in the next week or two.

b) Create installer packages.  I want to have one-click install packages for 
Windows, OS X and one or two Linux distributions.

c) Release, and discuss the merits of the UI.  It won't be particularly 
functional but it should give a pretty good sense of how you might use it and 
(for editing actions) what the workflow will be like.

d) Turn our attention to the backend.  I'll build on the s5 work I started last 
year, so hopefully I can put something together relatively quickly.  My goal is 
to have a somewhat faster release cycle with the backend work, perhaps having a 
new release as major features (scripting, saving and loading, networking) 
are landed.

e) Implement demos.  Actually, we should start thinking about this even now.

I've been thinking more about the big picture functionality, and I've decided 
that I want to focus on the simulation side aspects in a 3D environment.  That 
is, to have a framework that makes it easy to create a virtual world, add some 
agents (avatars, NPCs, whatever you want to call them) and then push play.  
The goal will be to address the needs both of games/entertainment (which are 
essentially discrete event simulations, albiet with rules that are 
intentionally unrealistic) and more serious applications such as AI and 
robotics research.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] progress and planning

2007-09-25 Thread Peter Amstutz
On Tue, Sep 25, 2007 at 07:44:04PM +0100, Marcos Marado wrote:
 Hi there, and thanks for the update.
 
 On Tuesday 25 September 2007 18:28, Peter Amstutz wrote:
  b) Create installer packages.  I want to have one-click install packages
  for Windows, OS X and one or two Linux distributions.
 
 For the Linux packages, please go to Debian and Fedora. Those two are 
 probably 
 the best two plataforms to release the most clean .deb/.rpm packages for 
 others to be able to repackage them for their own distribution.

As I noted in the other mail, I'm looking into using the epm tool 
(http://www.epmhome.org) so we only have to maintain a single script to be able 
to build binary packages for multiple distributions (including both deb and rpm 
based distros).

I personally use amd64 Debian, so I can generate 32 and 64 bit x86 deb packages 
pretty easily.  To support Fedora, I'll need to set up another partition, or 
maybe a virtual machine.  Hmm.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] development

2007-08-21 Thread Peter Amstutz
On Tue, Aug 21, 2007 at 12:28:55PM -0600, S Mattison wrote:
  The goals for the UI prototype is to explore how to present a highly
  configurable user interface based around vobjects, to consider the kinds
  of tasks and workflow a user might perform in the GUI, and to confront
  cross-platform issues (in compiling, in the operation of the GUI and in
  distributing binary packages) up front, so that development stays
  honest and as OS-neutral as possible.
 
 Wait, so, you mean, you're rendering the UI widgets in 3d now? (It
 sounds more and more like Blender each day.)

I'm not doing 3D widgets yet.  The UI is wxWidgets with 3D windows (as 
well as other views, such as a tree view) embedded in frames.  The 
frames can be split, unsplit, resized and detached at will, and each 
displays a different view which may be presented as a 2D control or 3D 
rendering, depending on the viewing mode.  It does have some 
similarities with the Blender UI, but it would be more accurate to say 
that the UI I am working on is more inspired by Emacs (!)

Eventually I want to be able to paint 2D views onto 3D textures so that 
you can mix 2D windows and 3D scenes freely -- but that will require a 
bit more work in creating/porting a GUI toolkit that can render to 
texture as easily as to the screen.

  By developing the UI first, I'm also taking a more top-down design
  strategy.  In the past, developing the backend first has led to the UI
  and the sample 3D worlds being an afterthought, which of course didn't
  impress most users.  To avoid making that mistake again, I'm going to
  focus on UI and content creation up front, to make good presentation and
  usability (and usefulness) a priority, and only then develop the backend
  to support those requirements.
 
 With Usability as a focus, you could attempt to allow users to create
 their own content, which I think should be the aim of a
 community-oriented project such as this one. More content means more
 popularity means more content, etc, etc.

Absolutely.  In fact since you mention it, I think I'll see if I can get 
the Blender - S5 Prototype export down to one click (writes the file, 
loads it into VOS for you).

  I'm hoping to have something for you all to see (UI prototype, with no
  network capability) in two to three weeks.
 
 Looking forward to it!
 -Steve

Good to hear :-)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] development infrastructure

2007-07-22 Thread Peter Amstutz
VOS development (specifically the next generation s5) is officially back 
on track.  I am now able to devote at least half of my working hours to 
VOS.

My time so far has been spent primarily on infrastructure issues.  I'm 
using the SCons (Software Construction) tool to develop a 
cross-platform build system.  A lot of things that in s4 are done with 
shell scripts and Unix commands can be done much more portably with the 
Python standard library.  The most useful feature for new developers 
will be automated downloading and compiling of dependencies, allowing 
one to start from scratch with only a few standard tools (Python, C++ 
compiler, make/nmake/vcbuild/xcodebuild as appropriate) and build VOS 
and all its dependencies with a single command.

Most importantly, this means that there is only one set of files 
describing the build, so there is no need to synchronize changes across 
makefiles, vcproj files, xcodeproj files and so forth.  However, since 
Visual Studio and XCode support makefile projects (which are easily 
configured to run SCons), you will still be able to use the IDE for 
development and debugging.

In order to ensure cross-platform compatability I will be testing and 
developing constantly on several platforms.  With the hardware sitting 
on my desk right now, I will be able to directly support Debian Linux 
(amd64), Windows XP (x86) and OS X 10.4 (x86).

On Windows XP I am using Visual C++ Express, which is a free-beer 
download from Microsoft.  Compiling on Windows requires only Visual 
Studio 8.0 and Python 2.4 -- no Unix tools required.  I haven't played 
around much with Cygwin and Mingw yet, but adding support should be 
relatively easy.

I intend to eventually implement a staged check-in system, where 
changes are run against a unit/regression test suite before being merged 
into the official branch.  That won't catch all issues (particularly 
those affecting specific OSs, since the branch will be hosted on 
interreality.org, which is amd64 Linux), but should still provide a 
firewall against dumb mistakes and help ensure that the public 
development branch is relatively stable.

It's been my experience with software development that the time invested 
in the software engineering process is paid back many times in time 
saved later, as many problems are caught before they are disruptive or 
can be avoided entirely.  I'm planning for the hopefully not-too-distant 
future when we have several developers hacking on VOS and need to avoid 
stepping on each other's toes.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] development plan

2007-07-22 Thread Peter Amstutz
Here's the big picture for VOS development over the next few months:

1)  Build out development infrastructure discussed in previous mail.  
This is mostly done.  The two main tasks are to refurbish an old 
computer I have to run Windows XP (waiting on parts) and to deploy or 
develop a staged commit system as I discussed.

2) Work on user interface prototype.  In the past, the end-user browser 
has always gotten the least attention despite being the first thing that 
everyone sees.  I am working on a minimal (lacking the underlying VOS 
structure) prototype GUI to stimulate discussion about the nature of the 
application -- how it will be used by newbies, developers, artists, etc.

3) Create distribution packages for the user interface prototype.  This 
serves two purposes: to enable people to try out and comment the UI 
without having to compile VOS, and to have the infrastructure in place 
to create .msi files, app bundles, debian packages, etc.

4) Concurrently with (2) and (3), I'm going to restart discussion of the 
s5 backend design.  I think I've got it all laid out in my head, I just 
need to write it down so you guys can pick over it.

5) Come up with some milestones and prioritize development.  The 
strategy will probably be to code enough of the VOS framework to support 
concurrent development of higher level pieces like A3DL, and to start 
putting some meat on the bones of the UI prototype.  This may be 
something like scripting + A3DL + application frontend (which could be a 
useful tool in its own right) without the networking, distributed 
computing and persistance pieces necessarily being ready yet.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] s5 design

2007-07-22 Thread Peter Amstutz
The overall project can be divided up into three pieces, the backend, 
the middle layers, and the frontend.  The frontend is the user interface 
(of which I will be presenting a prototype).  The middle layers consists 
of code dealing with specific features, such as chatting, representing a 
3D scene, how the 3D world is organized, login protocols, and so forth.  
The middle layer is heavily influenced by needs of the frontend and the 
capabilities of the backend.  The backend is the object management layer 
that enables everything else -- it is the actual Virtual Object 
System.

Here are some of the goals and key features for s5 backend:

 - Same basic Vobject model as s4, allowing vobjects to have 
multiple types and to connect to other vobjects through child links.

 - Vobjects now have an explicit computational/concurrency model based 
on Actors.  Each vobject is a separate logical thread of control -- in 
practice this will be implemented as a mix of user (cooperative) and 
preemptive (operating system) threads.

 - API oriented around asynchronous message passing and futures, 
allowing a method handler to return control to VOS and continue when 
some event occurs.

 - Language independent.  Vobject behaviors can be implemented in any 
supported programming language, and multiple languages can be used in 
the same process.

 - Object type definitions define cross-language interfaces and data 
models (such as A3DL).  Use code generation and reflection to create 
proxies automatically.

 - Architechture plans for distributed processing.  Vobjects can migrate 
between hosts.

 - Orthogonal persistance and caching.

 - Capability-based security and resource accounting (to eventually 
implement resource quotas.)

I'll talk more about how these pieces fit together in another email.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] thoughts and plans

2007-06-29 Thread Peter Amstutz
 something useful at 
 something faster than our current glacial pace.  If GUI elements are 
 somewhat modular as Pete seems to be suggesting (I.e. action/mode X 
 means load GUI panes Z and Y) then we can eventually replace 3D 
 versions if we want, down the road.

It's also worth considering that 2D overlays of a 3D view have 
disadvantages as well, they obstruct your view of the scene and have to 
be repainted every frame.  Having the 3D view embedded in a 2D GUI means 
the 3D view itself can be much less cluttered.  That said, we obviously 
want to support 2D overlays on the 3D view, and have the option of 
providing an immersive view.

But really the idea behind having major modes dictating the view is 
precisely to allow for having radically different views/interfaces to 
the same information.  There's no reason the 3D scene would only have 
one possible view.

This part is going to require a lot more design; one of the first things 
I am going to do is put together a GUI prototype (without the VOS 
backend) that provides a more concrete way of exploring this idea.

  If so, I am not sure what the mode stack in your mockup is for.
 
 Yeah, nont sure about this either. Is it a history of modes you used 
 to be in?

  Sounds fine, the only problem I see is how to determine that the user  
  is done with the current tool/minor mode. There sould be a consistent  
  and obvious way for the user to signal that. The current mode should  
  only be effective in the main part of the browser, with an  
  unobtrusive reserved mode selection area that is always available  
  and re-grabs mouse/keyboard bindings if you move the mouse over to it  
  or hit ESC or something.
 
 Well, is this what the mode stack window is for? I think various tools 
 could trigger mode transitions (bound to keys, mouse buttons, other 
 input devices). Anyway, we can just put them all in a menu too so you 
 can always have access to any of them as well.

Actually the idea is that you have a mode stack, and when there is a 
keypress or mouse event, it searches from the top of the stack downwards 
to the default major mode map.  The minor modes may be transient, for 
example you might push a rotate selected object mode to the top of the 
stack, this would alter the interpretation of mouse events (so that 
moving the mouse rotates the object on some axis) but not affect 
keyboard events.  When you're done rotating the object the rotate mode 
is popped off the stack and the mouse behavior returns to normal.  Some 
standard key (probably ESC) would cancel the current mode and pop it off 
the mode stack.

The toolbox on the right hand side would provide a list of commands 
that are valid in the current mode.

When I have some time I will put together a prototype to try and explore 
these ideas.  It's hard to discuss in the abstract, and I don't know 
myself how this will work -- I'm modeling it after the Emacs workflow 
(sort of) but Emacs is centered around the concrete notion of a text 
buffer, whereas the VOS editor is operating on vobject structures which 
are considerably more abstract.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] What do we want in the 0.24 release?

2007-06-29 Thread Peter Amstutz
Yea, we should probably have a minimum z value or invisible bounding 
box or something that prevents users from wandering out and falling off 
the edge of the world.  It's a silly, trivial feature we keep putting 
off...

On Fri, Jun 29, 2007 at 01:09:24PM -0600, S Mattison wrote:
 I mean in the Pyramid World. Outside the pyramid, there's only a
 little bit of room to run around before you fall of the edge. Perhaps
 at a certain depth, the player should respawn on the land, or inside
 the pyramid?
 
 On 6/29/07, Reed Hedges [EMAIL PROTECTED] wrote:
  On Fri, Jun 29, 2007 at 08:05:37AM -0600, S Mattison wrote:
   I can fall through the map. =P
 
 
  Well maybe you need a floor! :)
 
   Well, it's not difficult when there are no invisible bounding boxes
   holding me on.
 
  Actually it's several things
 
   1. Bounds in the world that terangreal can check, plus maybe an option to 
  turn
  bounds checking off
   2. Option to turn gravity off/on
   3. Option to turn collision detection off/on
   4. A fly mode that is initiated by fly keys that turn off gravity while 
  you're
  flying, then a key that turns it back on.
 
  1. is pretty trivial, 2 and 3 are trivial, 4 is not too hard but would take 
  a
  bit of work.
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] thoughts and plans

2007-06-29 Thread Peter Amstutz
(I wrote this in a private email to Reed, but I think it is of general 
interest).

What I have in mind could almost be a sort of desktop for VOS,
providing a general framework for providing visualization and
interaction for vobjects.  Thinking about it in that way, it might be
desirable to split different views into different processes, so they
don't conflict with each other and a crash doesn't take down the whole
system...  That approach would make it kind of like a window manager or
display server.

I'm thinking something like:
 vos io - abstract handling of input and output
 vos 2d - retained mode drawing using the SVG data model
 vos 3d - rendering based on A3DL data model (as we come up with it)
 vos gui - Abstract GUI controls represented using SVG or A3DL

VOS I/O is something we I haven't mentioned, but we will need a layer
that explicitly knows about key/mouse input events, and provides an
abstract representation for different means of output (character stream,
text console, graphical 2D and 3D panes).

I need to sit down and write some prototype code to explore this idea
more.  I'll probably hack out a GUI prototype with fake vobjects that
provide core functionality without all the asynchronous
communication/concurrency/network transparency features that will be in
the real VOS.

The week of June 9th I am officially part time, so that's when I hope
things will get going.


On Fri, Jun 29, 2007 at 09:09:36AM -0400, Reed Hedges wrote:
 
 I think we do need modes for keybindings, and I like the general tool idea.  
 The GUI should not neccesarily be directly mapped to mode.n ia fixed 
 configuration though.  Instead, there should be a set of GUI elements (side 
 panes, etc.) for each mode, but they should be flexible in that you can bring 
 up other GUI elements, minimize elements, and it should remember that layout 
 configuration for the next time you enter that mode.  And, mode transitions 
 should be tools/bound actions. For example, you define in configuration that 
 middle mouse click means to select an object, and also enter editing mode 
 with that object selected.  By entering edit mode, the GUI layout for that 
 mode would be displayed, which might include window panes with different 
 toolboxes or information about the object displayed. But maybe you want some 
 panes to always be visible in all modes, etc.; maybe you want to hide the 
 chat 
 pane while you're in edit mode or minimize it so that there's a little button 
 on the edge of the screen that brings it back, etc.
 
 I think tool panes/sidebars that you optionally float and move or iconify are 
 a 
 useful way to present buttons, tools, and object trees that makes them easily
 accessible and viewable.
 
 (We should also definately adopt Firefox's method of displaying background
 notifications and non-modal dialog boxes by inserting them above or below the
 main viewing area rather than as popups :)
 
 Reed
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] thoughts and plans

2007-06-27 Thread Peter Amstutz
On Wed, Jun 27, 2007 at 12:29:43PM +0200, Karsten Otto wrote:

   - Scalability, clustering and recovery from failure.  The general  
  ideas
  is to use replication for load balancing and distributed locks for
  consistancy control.
 
 This sounds like a radical redesign... so far we had a single local  
 vobject acting as a sequencer for multiple remote vobjects.  
 Obviously, you have something new in mind. Please tell us more :-)

I'm shamelessly stealing from Croquet, actually :-)

The general idea is to roll up clustering, caching, persistance and 
remote objects under a single replication design.  After all, what is 
the purpose of a distributed system but for managing copies of objects?  
So, the focus of the design will be on locating, replicating and 
synchronizing objects, whether the copy comes from a cache, a site, or a 
member of a cluster.  This has a few implications:

 - The core vobject data model needs to include property data (a 
direction we were already going with embeded children) so that the 
entire potential state of the vobject is known and explicit.

 - The vobject model needs to have a canonical serialization that can be 
used for checking hash codes.  However, this won't affect the ability to 
have multiple encodings used for data exchange.

 - Vobjects will need revision numbers and possibly last-modified times 
used in conjunction with the hash code to assist in determining if a 
copy is out of date.

Once the ability to read and copy vobjects is established, we still need 
to deal with how to write to them.  The design will attempt to move away 
from explicitly differentiating between local and remote objects, 
and instead look at whether the object's site is local or remote.  
For remote objects, it is a simple matter of forwarding requests to the 
remote site [1]. In the case of clustering, the same site might owned by 
several processes, and a distributed locking protocol (or alternately a 
distributed transaction) will establish which node owns the vobject.

[1] I'm still working on what kind of speculative execution should be 
allowed on the client side.  It is easy to service a read request on a 
cached vobject, more difficult to execute code that will actually change 
this vobject and others, and could have a ripple effect on the system 
that would have to be rolled back if the request was denied.

A couple of key differences from Croquet: I'm concerned primarily with 
replicating end results, not computation.  Croquet works by requiring 
that all Croquet simulations accept the same input in the same order and 
produce the same deterministic results.  This is troublesome in a 
heterogenous environment where different versions of software (and even 
entirely different implementations) need to work together.

Second, I see distributed object ownership as being done primarily in a 
high performance or high load situation where a compute cluster makes 
sense.  There's no reason it couldn't be done between peers on the 
Internet, but it requires parties trust each other -- distributed 
ownership implies that there is no way to enforce access control between 
peers.  In most situations, which are more security conscious, you have 
a more typical centralized design (in terms of world ownership being 
located on a single site) accessed by clients which issue checked change 
requests.

I should mention that clustering isn't planned for 1.0, but I'm 
considering it now to ensure the design and implementation will be able 
to grow and support it later.

On a separate note, another goal is to support more data-oriented 
networking and routing, inspired by the Van Jacobson talk we discussed 
earlier.  Fully qualified vobject identifiers will be 
address-independent (unlike s4, which uses domain names and as a result 
suffers from a number of aliasing problems) which will allow parties 
other than the actual vobject owner to route messages and serve vobject 
replicas, through careful use of digital signatures to prevent forgery.

   * It should be designed to permit plugins or extensions to its
  functionality.
 
 I would go a bit further here - use plugins as the *basis* of the  
 software!
 The main client only needs to provide capabilities for displaying  
 (layered) 3D content and manage plugins. Everything else should be in  
 the plugins themselves. See below...

Yes, I agree.  The Emacs model is to provide a relatively small kernel 
of functionality, with virtually everything else built up as an 
extension.  I'm hoping that the extensions can be written in Python 
and/or Javascript.  The key insight for me is in considering, from a UI 
and application design perspective, what the kernel for the 3D VR 
browser actually needs to provide to have the right hooks that the 
extensions can grab on to.

I'll see about replying to some of your other points about UI later 
(right now it's late.)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer

Re: [vos-d] 3D engines

2007-06-27 Thread Peter Amstutz
Well, one thing I was trying to get across is than VOS doesn't care that 
much about a lot of these game engine features, because we are going 
to be doing things our own way as part of our own design.  I.e. we don't 
care if an engine has a native map format with scripting hooks, because 
we're going to be using A3DL and our own scripting system.  We just 
need a good, high level 3D renderer.

On Wed, Jun 27, 2007 at 12:29:10PM +0800, chris wrote:
 Hi Peter, just one comment, it is proly not right to compare Ogre with a 3D
 game engine.
 Might be better to look at a game engine built on Ogre - like GOOF.
 
 chris
 
 On 27/06/07, Peter Amstutz [EMAIL PROTECTED] wrote:
 
 Many of the support features of various engines (map editors, or support
 for certain modeling programs) are less useful for us, since we will
 ultimately need to convert data to and from the engine-neutral A3DL data
 model for transmission over the network.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] thoughts and plans

2007-06-26 Thread Peter Amstutz
 and 
Blender, possibly with some Visual Studio-style detachable pop-out 
windows (using wxAUI) thrown in for good measure.

It's crazy, but it just might work.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] 3D engines

2007-06-26 Thread Peter Amstutz
The developer of the Lightfeather 3D engine (an offshoot of Irrlicht, 
since rewritten) has expressed an interest in working with us, so I 
wanted to mention the idea of moving primary development from Crystal 
Space to another 3D engine.  Since I am rewriting Ter'Angreal either 
way, I don't have a strong opposition to changing engines, but I don't 
(presently) have a strong reason to switch, either.  The crucial 
features are that it be cross-platform, fast, unobtrusive (easy to 
subordinate to the WxWidgets or VOS event loop) and support a few 
crucial features we need, like portals and skeletal animation.

Other 3D toolkits I have considered include Open Scene Graph and Ogre.  
I suspect that at this stage of development, most 3D engines are more 
similar than different -- they all use OpenGL and the same shader 
languages (Cg or GLSL), which accounts for about 90% of the end result 
of rendering.

Many of the support features of various engines (map editors, or support 
for certain modeling programs) are less useful for us, since we will 
ultimately need to convert data to and from the engine-neutral A3DL data 
model for transmission over the network.

Thoughts?

Lightfeather:
http://lf.mmdevel.de/news.php

Crystal Space
http://crystalspace3d.org

Open Scene Graph
http://www.openscenegraph.com

Ogre
http://www.ogre3d.org

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Listener notifications in S5

2007-06-07 Thread Peter Amstutz
On Thu, Jun 07, 2007 at 07:31:42PM -0400, Reed Hedges wrote:
 
 How do listener notifications fit in with the S5 
 vobject-as-logical-thread idea? I'm thinking specifically about impact 
 on ability to scale number of objects that one listener is listening to. 

Well, my primary concern with the listener system is that if you are 
interested in a large number of vobjects, the s4 model of adding a 
listener to each vobject individually has a lot of overhead and 
redundancy.  However, because we want to be able to support multiple 
worlds hosted in the same process (or a world segmented over multiple 
sectors) it's not desirable to broadcast every update to every 
potentially interested party.

The general strategy I have in mind is to have updates sent to some 
intermediate vobject that represents a group of vobjects.  Then becoming 
a listener to that intermediate vobject would be sufficient to be able 
to listen to the entire group.

I'm not sure about the best way to define this group.  One possibility 
is to define the group as a vobject's subtree of children.  In this 
scheme, update messages would be sent to the vobject's parents and 
passed up to the hierarchy to the relay vobject.

Another way would be to maintain something more similar to the current 
system, continuing to maintain listener lists on each vobject, and 
permit an interested party to listen directly as well as having the 
relay vobject also listen to each vobject.

Generally speaking, some kind of chain of lists of listeners -- going 
from the most specific to the most broad -- seems like the right way to 
go.

I'm guessing listener notifications are processed same as any other 
 messages in the vobject's message queue/thread, right?   How would you 
 set up parallel notification processing? Create a little listening 
 vobject to recieve the notification on the main vobject's behalf, perhaps?

Parallel notification processing is one of the things that got us into 
the awful mess that is the s4 Crystal Space plugin to begin with, so 
requiring notifications to be processed serially is not something I 
consider to be a problem.  The vobject can pipeline requests (start 
processing the next one while waiting on something for a previous one) 
or spin off additional vobjects to do parallel processing if such a 
approaches make sense.

 I wonder if we want to enrich the core listener types in S5 a bit, by 
 adding conditions that can be checked before sending a notification for 
 example.

The main challenge with conditions is you either have to define a fixed 
set of predefined conditions, or create a minilanguage in which you 
write your arbitrary conditional expression.  Easier said than done, in 
other words.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Errors building crystalspace

2007-05-30 Thread Peter Amstutz

On Tue, May 29, 2007 at 06:58:36PM -0400, Reed Hedges wrote:
 
 OK, it turns out this is just G++ 4.1.3 being stricter than older G++'s.
 
 Our CS branch actually had a partial fix for this problem but - 
 bizarrely - it was conditional on the compiler being MSVC 7.1!!  I 
 looked at current CS svn and it just declares csPrintFormatter and 
 IEEEwhatever::mantissa correctly  to begin with.

 I'll commit this to our crystalspace branch.   How do I regenerate the 
 .tar.gz?

Use /home/bzroot/vosscripts/makeexports

 Incidentally, crystalspace.tar.gz is humongous. To redownload it in less 
 than a few hours on my dialup connection I went in and deleted a bunch 
 of stuff from the scripts/msvc* directories, the entire data directory, 
 and some of the plugin code we don't use.  Maybe we should do the same 
 for our branch (at least delete the data directory).

Careful, I'm pretty sure there are some essential CS config files stored 
in the data directory.

 I might also change vos/m4/cs.m4 to only compile some of the CS 
 plugins instead of all of them (many of which terangreal does not and 
 will probably never use).

Go for it -- anything that reduces build time is helpful.  The main 
challenge wrt to CS plugins is that some plugins rely on other plugins, 
so it takes some work to actually determine which plugins we're using 
and which ones we arn't.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24

2007-05-16 Thread Peter Amstutz
On Tue, May 15, 2007 at 11:24:07PM -0700, Ken Taylor wrote:

 The point is I've noticed that in 0.23 the blacksun pyramid seems a lot ...
 smaller than in 0.24. Or maybe the penguins are bigger. Also, if I have 0.23
 and 0.24 clients connected to the same server, the 0.23 guys look like
 they're floating above the ground to the 0.24 guys while the 0.24 guys look
 like they're half way in the ground to the 0.23 guys.

 Obviously some scaling and origin placement has been tweaked between
 versions. I just wanted to make sure this was intentional :) -- and also
 suggest that re-scaling 3d data should be added as a cleanup task before
 releasing 0.24. (Speaking of which, is a goal/to-do/priority list for 0.24
 coalescing anywhere?)

Yes, I changed the penguin sizes in 0.24.  I did the math and realized 
they were about 40cm tall, and were intended to be a bit bigger than 
that.

The bigger problem was I was doing something dumb in 0.23, which was the 
code that loads the md2 models for avatars recenters it to make the 
origin the center of the avatar bounding box rather than at the avatar's 
feet.  That's why the 0.24 guys appear to be halfway in the floor when 
viewed using 0.23.  Also, the avatars feet not touching the floor has to 
do with the collision bounding volume not matching up with the avatar 
(which is something else I was fiddling with).

Since most of the work has gone into the network layer, a lot of stuff 
in the 3D layer was a quick proof of concept rather than being really 
well thought out.  Even if s4 - s5 transition wasn't necessary, an A3DL 
redesign was already on the plan.
 
 Also it made me think about standardization. Obviously, VOS/Interreality3D
 will eventually have to have a golden standard for networking and data
 encoding. But also obviously, there will be lots of tweaking until a good
 standard is found (given VOS's code-evaluate-recode development approach).

Speaking of the code-evaluate-recode cycle, I want to mention here that 
that come July, I intend to go part time on my current job and spend the 
rest of my time on VOS, which should work around to around 20 
hours/week.  Although it's not full time, I expect this to make a huge 
difference in the pace of development, especially since the majority of 
design work has already been done, so most of the work is will be just 
sitting down and coding.

 Until that standard is finalized, everyone will have to make sure they're
 using the same version of clients, servers, and data sets, to ensure
 consistency. But at some point, perhaps VOS/Interreality 1.0, a standard
 needs to be set in stone, with a guarantee that objects will be interpreted
 in consistent ways, that newer versions will be backwards-compatible, and
 older versions will fail gracefully if presented with newer data. A standard
 that's unambiguous enough that a person who's never seen the VOS codebase
 could write their own client and server from the standard itself, and also
 guarantee that compatibility.

Well, that's a pretty tall order, and codifying standards is premature 
until we've settled on something that works.  However, what is important 
at this point is to plan for backwards compatability, which is something 
I mentioned in an earlier email.  In s5, I want to lay out a set of 
rules by which certain object fields and message signatures can be 
automatically casted, sliced or extended to allow structured data not 
conforming exactly to expected format to be converted.

I think VOS should be able to offer very good compatability and 
consistency by providing the developer with guidance on what kinds of 
interface changes affect backwards compatability, and giving some 
flexibility so that not every teeny tiny little change requires an 
incompatible upgrade (which is the situation with most protocols in 
general, but virtual world systems in particular, such as Second Life 
having to frequently distribute client patches and reboot their grid).

So rest assured, it's something we're thinking about, and have been 
thinking about for a long time -- making it general purpose and doing it 
right is one of the reasons VOS development has taken so long.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24

2007-05-16 Thread Peter Amstutz
On Wed, May 16, 2007 at 12:10:21PM -0400, Reed Hedges wrote:
 On Wed, May 16, 2007 at 10:18:34AM -0400, Peter Amstutz wrote:
  The bigger problem was I was doing something dumb in 0.23, which was the 
  code that loads the md2 models for avatars recenters it to make the 
  origin the center of the avatar bounding box rather than at the avatar's 
  feet.  
 
 So now it uses the bottom extent of the md2 model as the origin for the
 vobject's polygons? Shouldn't it use the same origin as in the md2
 model, and if the origin is wrong there you just have to fix the model?
 (Or I guess we could have a flag in a3dl:model that decides this, since
 it's possible that people won't want to have to go back and change the
 source models, especially if you have a nontrivial workflow involving
 several artists and programmers).

Unfortunately, just fix the model is often much harder than it sounds 
in the real world.  For example, a lot of 3D models in the wild are 
exported from 3D modelers rather than being in the native modeler 
format, so you lose useful editing data, or maybe you have the original 
model file but don't have the right version of the modeling program that 
was used to make the original model.  3D file format compatability is 
such a big problem that this can even happen in organizations that might 
want to reuse content made for an earlier project.

In this case fiddling with the model in code was due in part because I 
already needed to rotate the md2 model by 90 degrees so that it faced 
forward (this to get around a bug in the underlying md2 loader in 
Crystal Space).

For the s5 redesign, I would prefer to avoid the current 
a3dl:object3D.model approach entirely, which was just an expedient hack 
to be able to leverage the Crystal Space modeling loading at the cost of 
the model data being opaque to A3DL.  Instead we should write filters 
that convert to/from a unified A3DL format.  Normalization should happen 
in the import step, rather than in the client.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] delineation and revision control

2007-05-09 Thread Peter Amstutz
Let's see if I can clear up a few things...  Bear in mind that the 
design is still evolving in my head :-)

a) From the perspective of VOS, which is concerned with synchronization, 
the most important purpose of versioning is so you have a basis for 
deciding whether your replica A' of vobject A is current or out of date.  
Being able to record changes and go back into the history is just a nice 
side effect.

b) Each vobject would be versioned separately.  The child list is part of 
the versioned state, but a change to a child vobject should not affect 
the version of the parent.  One exception: embedded children (property 
fields) do affect the version.

c) The big picture I'm going towards here is that remote vobjects, 
caching, scalability/load balancing and the kind of broadcast routing Van 
Jacobson talks about are all basically cases of replication.  If the VOS 
design can unify these cases under one general solution then we've won.

I need to develop the idea more, but I think one key idea is relaxing the 
idea of a site so that it doesn't have to be tied to a specific host.  
I had already decided that sites would be identified by their public key, 
so that messages distributed by the site are self-verifying (by checking 
that the digital signature matches the site id).  This means if you want 
to query a vobject, any replication -- the actual host site, a local 
cache, a third party -- can answer, and you can check that the answer did 
in fact originate from the site.  What's really interesting is that this 
means the authority to publish changes to vobjects rests in who has 
knowledge of the private key that corresponds to the site's public key.  
If you wanted to do load balancing/clustering, you could share that 
private key among several trusted hosts, any one of which would be able 
to issue official state changes for vobjects on that site.

I should point out that in the most common case, hosts will be in direct 
contact with the actual site, and receive messages published from the 
site directly, so it's not any different from the way things work now.

Getting back to Kao's question (which I've wandered quite far away from), 
as noted the synchronization principals in the system are the site and 
individual vobjects.  I don't see how cycles and bounderies between 
subgraphs factor into it, except perhaps in the initial phase of 
determining the specific subset of vobjects on the site you're interested 
in.

On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote:
 Well, Lars' suggestion of versioning only interesting parts and  
 your suggestion of horizons seem reasonable, but I don't think we  
 have the basis for this in VOS. A vobject usually cannot live as  
 isolated entity, but *requires* a number of relations to child  
 vobjects to make sense; thus any user-percievable world object is  
 actually a subgraph of the overall world graph.
 
 The problem is delineation: It is not clear which subgraphs represent  
 independent world objects, or if there is even a distinctive  
 decomposition. For example, two objecs may share a texture - which  
 vobject does it belong to? If you change one vobject, do you  
 include the texture in the version? Where do you stop following  
 relational links? I don't recall if there is any prohibition in VOS  
 against cycles in the graph - I think there isn't - so matters become  
 even more complicated.
 
 The only separation I currently see in VOS is the relation between  
 the site vobject and its children, but even here it is not clear  
 which children represent aspects of the site itself, which are  
 scenery, and which are avatars.
 
 Any suggestions?
 
 Regards,
 Karsten Otto (kao)
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Van Jacobson: named data -- revision control

2007-05-09 Thread Peter Amstutz
I don't think Jacobson was suggesting that a really new paradigm in 
networking would be able to handle the robust case of broadcast data, of 
which unicasting is simply a subset.  I find you need a little creativity 
to fill in some of the gaps in the later part of the talk, since he 
wasn't presenting a design (or really, even a complete theoretical 
architechture) but simply some big ideas that he thought were worth a lot 
more attention.

Packet switched networks are fine for realtime communication, provided 
there is enough bandwidth and they arn't congested.  That performance 
degrades rather than simply shutting down and/or denying new connections 
is a feature, not a bug.

As you point out, no existing system adequately fufills the requirements 
of online virtual worlds which precisely why we've spent so much time 
building our own.  The problem is a curious mix of large quantities of 
mostly static data (3D models, textures) punctuated by dynamic data with 
high frequency changes and requirements for low latency.  Throw in 
streaming media to the mix (voice) and it's really an architechtural 
nightmare when you consider the vast majority of network research has 
been in trying to solve each of these problems in isolation and to the 
exclusion of the others.

The reason broadcast routing is so exciting is that we're not just trying 
to solve how to move the latency-sensitive high-frequency bits around, 
but that distributing and caching static resources (geometry, textures) 
is a huge part of the problem, and one that we never adequately addressed 
in the current/old s4 design.  Indeed, moving the latency-sensitive 
high-frequency bits around is easy, because there isn't that much of it, 
and the problem was largely solved by online games ten years ago.

On Wed, May 09, 2007 at 12:10:16PM -0700, dan miller wrote:
 Hi --
 
 I'm new to the list though I have been on IRC now  then.  
 
 I loved Jacobson's talk but one point struck me: the introduction of a new
 paradigm doesn't obviate the need for the old.  Packet-switching is great
 for fault-tolerance when the goal is get this packet from here to there, no
 matter what.   It's actually the postal paradigm (thru wind  sleet...)
 
 But the old telco real-time, hard-wired point-to-point connection was
 actually better suited to some things we do today over packet networks,
 particularly teleconferencing.  The control over latency and timing is lost
 when you switch to TCP (as you VOS folks know only too well).
 
 A data subscription model is really just a cool technological way to
 introduce the concept of publishing to the digital world in a useful way;
 but it doesn't change the fact that packet-switched networks are not so
 great for realtime communication.
 
 WRT VOS/Interreality goals, in particular avatar/object behavior (whether
 scripted or resulting from user input), we have a mix of requirements that
 doesn't easily fit any model I'm aware of.  It's time critical, like a phone
 conversation; it's point-to-many-point, like publishing; it's ephemeral,
 like broadcasting; but it's not fully global, in that typically you only
 care about a few objects in your virtual vicinity.  Distributing this data
 liberally is not an option due to bandwidth.
 
 The bittorrent model doesn't really wash here because of the requirement for
 low latenc.  I think in this case we have another animal entirely, which is
 basically a secure multipoint channel cluster.  The closest analogy I'm
 aware of would be multi-party teleconferencing.  ATT actually does this
 pretty well.
 
 This animal should be optimized for its intended use, and not shoe-horned
 into paradigms that it doesn't really fit.  It might be reasonable to take a
 look at some of the ITU work in this area, such as H.323, and even the IETF
 VOIP/SIP stuff that's out there.  
 
 I'm not saying we should necessarily adopt any such standards; but it is
 often worthwhile to take a good look at how similar problems have been
 tackled, for better or worse.  Otherwise you risk spending mucho time
 reinventing various types of wheels.
 
 -dbm

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Van Jacobson: named data

2007-05-08 Thread Peter Amstutz
Well, on a technical level you have digital signatures that give you a 
technical way to verify that information from a given source has not 
been tampered with.  Provided you trust that the public key used to sign 
that data did in fact come from that entity, of course, but trust has to 
start somewhere.

On a social level, you're right, people tend to introduce errors (either 
accidentally or deliberately) in information.  There isn't a technical 
solution to that.  But that's not the kind of transmission we're dealing 
with; we're only concerned with exact digital copies.  Whether the 
source itself is an eyewitness account, a newpaper article or a 
wikipedia writeup, the goal is simply propagation of the actual digital 
document without allowing for the introduction of errors into the 
document itself.

On Mon, May 07, 2007 at 10:20:55PM -0500, Len Bullard wrote:
 Versioning yes, but also vetting and revetting of sources.  The further you
 get from original sources in any communication system, the more noise you
 incur without adequate checks.  Shannon 101.  Names alone won't do it.
 
 I put a trivia test at my personal blog just for a Do you trust Google and
 Wikipedia test.  The problem is one of not starting from an authenticated
 or original source.  If you start from wikipedia to answer those questions
 without the original source, you will get about half of them wrong or near
 wrong.
 
 Modern Internet traffic worries about efficiency but typically the data is
 short lived.  If you live where I live you get to watch a fascinating
 change: NASA is hiring as many sixty and even 70 plus year old engineers as
 they can find if they have actual J2 series engine experience.  The original
 sources and digital systems failed to keep enough documents alive.  They
 have the designs but like the Canadians who tried to rebuild the V2 engines
 for their contest submission, they don't know how to run them and it turns
 out the devil is really in the details.
 
 len

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Van Jacobson: named data -- revision control

2007-05-08 Thread Peter Amstutz
On Tue, May 08, 2007 at 03:56:07PM -0400, Reed Hedges wrote:

 There are lots of ways to do version control in VOS-- we already have it
 partly implemented.  One important thing that we need to decide is how
 to expose particular object revisions to remote sites. I think we need
 to be able to refer (by URL) to both the current version, or to any past
 version (in all ways as a normal vobject, with all interfaces, etc.)

Right.  I think the key is going to be to start thinking about remote 
vobjects as simply replications of the actual vobject, and which means 
those replications use the same system to be stored on disk (cached) or 
passed around.  The vobjects just happen to be associated with a 
different site; but I think it's worth considering relaxing the concept 
of site to its simplest form of a set of vobjects covered by a common 
public key, and that sites have a standard (replicated) vobject that 
contains its contact information.  Then if you ask one host how to get 
in contact with some other site, it gives you that replicated contact 
information.

Another crucial aspect of replication that keeps coming up is 
computation: I think when we replicate vobjects, we'll need to indicate 
whether it's computation can be replicated as well.  As I stated in my 
previous email, this could be don't replicate (can't do anything with 
an object without contacting its original site), predictive 
replication (both contact the server and do the computation locally) or 
full replication (always run it locally and don't contact the server).

I've been thinking about replication a lot due in part to reading about 
how Croquet works.  However, where Croquet assumes a totally 
deterministic system (which makes replication of computation easier), I 
want to allow for a little more slack, provided you always have the 
ability to bring everything back in line.

This is worth thinking about more, since it has pretty fundamental 
design implications, but is also central to how remote vobjects work, to 
caching, to versioning, and to scalability across multiple nodes.  
What's interesting is this is a shift not in how vobjects themselves 
work, but in how they move between hosts.  I also think that for all 
this seeming complexity, that in fact in the cases where it matters, 
most of that complexity shakes out and it can still be very efficient.

 This means that if that version object is mutable, i.e. a not read-only
 property, we need to also have branches in the version history, and any
 reference to a past version of a vobjcet is really a reference to the
 most recent version in the branch rooted on this object, which if there
 is only one version in the branch, is the same as the root object [if
 that makes any sense].

I don't understand.  Lalo will undoubtedly correct me if I'm wrong, but 
it seems to me what is most important is linear version history leading 
up to specific object.  Branches mark the point at which item Y diverged 
from item X, which in this case would likely mean item Y would be given 
a new vobject id, or possibly have the same id but located on a new 
site.  We could save the fact that it branched as metadata (maybe a 
core:branch-history vobject type), but it shouldn't be part of the 
fundamental vobject id.

I should point out here that you don't actually *have* to keep a version 
history around, that's just a nice side effect.  So long as you bump up 
the version number with each change (and timestamp, and regenerate the 
digital signature, etc) you have a simple way to compare your vobject 
replica with the master version on the site to decide if you need to 
synchronize or not.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Jerky avatar movement (was Re: Patches for 0.24 in MSVC)

2007-05-05 Thread Peter Amstutz
On Sat, May 05, 2007 at 02:04:01PM -0700, Ken Taylor wrote:
 Wait... unless the purpose of rot *was* to caputre and restore the
 previous position, and force all position updates to go through the
 setPosition/notifyPropertyChange mechanism in that case, the main
 problem is you can't guarantee that the property change will trigger a
 syncPosition that executes *before* syncView reads the new position. So what
 was happening is syncView had the latest position, but the mesh hadn't been
 moved there yet, so the avatar lagged behind in some frames causing the
 jerky movement.

Pretty much, yes.  To be perfectly honest, avatar control in ter'angreal 
is kind of a hack.

 I think immediately moving the mesh upon a local move command isn't such a
 bad idea, but the fact that an asynchronous property update gets triggered
 and executed at some time in the future, which *also* moves the mesh, is a
 bit troubling to me. This is also concerning me because it impacts my
 interpolation code -- what happens if you do a local moveTo on an object
 that also can be moved remotely? When do you interpolate and when do you
 update immediately? Any thoughts on what the Right Way to implement this
 would be?

I'm not sure...  As you note, it's tricky because you have both local 
movement commits and the possibility that it can be changed remotely, 
and that change should stick.  It's kind of a race condition, actually, 
which is why it's hard.  The Right Way is probably to fix the semantics 
of property updates to handle this better, but that's more of something 
to consider for s5...

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Movement interpolation update

2007-05-05 Thread Peter Amstutz
On Thu, May 03, 2007 at 04:23:38PM +0200, Karsten Otto wrote:
 Funny... the problems you mention actually result from a lack of  
 semantics!
 ...
 The only *real* solution, both in S4 and S5, would be what the games  
 do: Send a custom movement message... and loose the genericity of  
 the VOS platform.

This is actually really insightful.  We talk a lot about how it's easy 
to extend the semantics of vobjects.  Why not be able to extend the 
sematics of messages?

Presently, types list their entire inheritance in the name.  For 
example, a3dl:object3D.sphere is in the a3dl namespace, is an 
object3D, with additional semantics indicating that it is a sphere.  
If a program doesn't understand (or doesn't care about) the type 
a3dl:object3D.sphere, it is permitted to interpret it as just 
a3dl:object3D.

Why not do the same for messages?  For example, core:property-replace 
could have specializations core:property-replace.movement and 
core:property-replace.teleport.  Your implementation could handle them 
separately, and they would be permitted to have additional fields, but 
would indicate explicitly to the interface that the action (and fields) 
is an elaboration on core:property-replace.  Such messages could be 
sliced to their simpler versions if a handler for the specialization 
isn't available.

 My hope is that this problem might get smoothed over a bit in S5. I  
 assume that both position and orientation will likely be embedded  
 children of an avatar vobject. If you change both, you need to  
 acquire the lock of the parent, change the values, and release the  
 lock (ok, VOS will do this for you transparently). In this case, VOS  
 should defer the update notifications until the parent lock gets  
 released, and the send them all in an atomic compund  
 update (message block?) which is semantically slightly closer to the  
 actual user action. I am not quite sure how you could squeeze a  
 don't-interpolate flag into the mix though - unless it is an actual  
 embedded child of the avatar vobject, which is somewhat messy.

What you want is a transaction system for updates.  This is something 
I've been mulling over for awhile, but haven't really found a good way 
to do it yet.  The problem isn't so much for transactions themselves, 
but that we also was atomic *notify events* so that if I perform a 
transaction that changes three values, listeners are notified in such a 
way that they can know that the entire set of values changed at once, so 
they get a single atomic callback and not three callbacks for each of 
the three values that changed.  That's what makes things like physics 
work, where position and velocity need to change atomically.

Any thoughts on a good model for this?  The s5 design is going to make 
this easier, I think, because instead of strict callbacks for notify 
events, it will use the same message passing system as for method calls.  
This might make it easier to implicitly or explicitly recognize cases 
where notify events should be combined.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] build system reviews (long)

2007-04-27 Thread Peter Amstutz
Uh, I don't think giving everybody accounts on baikonur (the 
interreality.org server) is going to solve much.  For one thing, it only 
runs Debian, and a big part of the discussion here is how best to 
support building on Windows and OS X.

We intend to do 3rd party world hosting at some point in the future, but 
that will go on a separate box from interreality.org.  I don't want to 
take the risk of a rogue script disrupting the box that handles our 
email, web page, mailing list, bzr repositories, etc.

On Thu, Apr 26, 2007 at 01:02:08PM -0700, HEBLACK, J wrote:
 On Thu, 2007-04-26 at 09:21 -0400, Reed Hedges wrote:
  On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote:
   [1] Although there is a case to be made that such files should be 
   included in your repository anyway, since there are people who might 
   want to check out the latest source for something but still don't want 
   to be required to have every last little build tool.  Thoughts?
  
 
 Hello people,
 
 How about installing a sandbox or build sandbox at the main VOS
 station for devs to link scripts, Java, JavaScript, ..., whose scripts
 would not disturb Lead Programmers or VOS Architects. Thoughts? The
 official sandbox will have network constraint conditions saying that
 what is built officially is there for the VOS station only and not other
 networks? A sample devs account is like this: the first six letters from
 the devs last name followed by the first initial from the devs name;
 like this: [EMAIL PROTECTED] 
 
 
 -- 
 JASON A HEBLACK [EMAIL PROTECTED] 
 APT 3   (650) 289 - 0954
 450 EAST O'KEEFE 
 EAST PALO ALTO, CA  94303  
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 scripting (design part 3)

2007-04-26 Thread Peter Amstutz
 will be used for, and so they should be allowed to do it.  
However, for breaking out of the sandbox in general, with a capability 
system we can grant relatively narrow and specific rights to a script 
that requires escalated privilidges.

 4) An object on the server contains a script to be run client-side, perhaps
 to perform some special animation effect or to support some custom
 interaction with the server, and the user of the client can decide to accept
 that script or not.

I haven't decided how to handle sending code from the server to the 
client.  One approach would be to go to the relevant type vobject on the 
server and retrieve the remote interceptor which provides the remote 
vobject behavior that acts as the proxy on the client for the real 
vobject on the server.

Everything I have said here about server-side process accounting, 
resource limits and security applies equally to both the server side and 
client side.  You don't want a malicious script to take over your 
desktop any more than you want it to take over a server with hundreds of 
people on it.  The main difference is that on the client side we have 
the option of asking the user if something is acceptable, instead of 
just rejecting it outright.  Deciding whether to actually run a script 
based on some client preference (maybe it's an annoying dancing 
advertisement) rather than having evidence of the script misbehaving is 
rather more difficult.

 Also: will interreality specify any default languages to be supported as a
 baseline, or will it just be whatever runtimes the current server has
 installed? Will there be a way to query the server for what runtimes it
 supports, and what capabilities those runtimes have? Can an object (such as
 in case 4) have multiple languages attached to it, so the client can pick
 which one it supports the best? Can a script specify at the outset what
 capabilities it requires so the vos kernel can decide whether or not to even
 run it (or to ask the user to allow certain capabilities)?

Yes, we'll want some way of asking the server it's configuration, to 
find out what scripting languages (among other things) it supports.  
Letting mobile code be written in languages seems like a recipe for 
disaster though, since the two implementations were identical (and the 
standard well documented), you might get significantly different 
behavior in one runtime compared to another.  I suppose you could 
translate from one programming language to another automatically, but 
I've never seen that done well...

Since detailed process accounting for CPU and RAM are going to be hard 
to accomodate with existing scripting systems, the idea for the time 
being is to use existing scripting languages, but in a trusted 
capacity -- we might enforce the VOS security model for vobjects, but 
not worry about so much about CPU, RAM and disk usage.  This should 
allow us to support a few languages on the server right off the bat.  
However, this is unacceptable for mobile code.

For code that is transferred over the network and is run on the client 
or server without user or admin intervention, we will need to identify 
some runtime system that satisfies our strict process accounting and 
security requirements.  This will probably end up being the default 
language at least so far as client and server side scripts written by 
untrusted users are concerned.  Ideally this would be a virtual machine 
and not just a single specific language.  I haven't found a good open 
source implementation of a virtual machine that satisfies our 
requirements, yet.

So to sum up, for me the biggest challenge of scripting is to make it 
bulletproof secure, so that it can't be used by either clients or 
servers to take advantage of the other.  I'm hoping to use a capability 
system to enforce security in interactions between vobjects (which I 
will try to do a writeup on soon, that will be part 4 of the s5 design) 
but process accounting to see that everyone gets their fair share of 
CPU/RAM is still a huge challenge.  I don't want my scripting languages 
in a sandbox, I want them in a bulletproof jail cell...

 ps: Something else that may be interesting -- having a special VOS 
 translation layer that lets one run scripts wrtten for VRML nodes in a 
 VOS world. This could facilitate importing VRML files transparently.

Reed and I have been thinking about doing this for years.  The idea was 
to use OpenVRML to provide the VRML runtime environment, and then 
translate VOS events to VRML input and vice versa.  I think it's 
feasable, we've just never had the time to implement it.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature

Re: [vos-d] VOS on Solaris?

2007-04-25 Thread Peter Amstutz
On Wed, Apr 25, 2007 at 11:33:49AM +0300, Lars O. Grobe wrote:
  Do you have libtool installed?  That is a separate package from autoconf 
  and automake.
 
 I compiled the most recent one from GNU. As I am not root, I installed 
 it in my home and added it to my PATH. Does the build make any 
 assumption where to find libtool (e.g. under /usr)?

I think you need to also set an environment variable to the installation 
location of libtool, but you will have to check the documentation.  When 
I was developing on Solaris I had to set up autoconf/automake/libtool to 
run out of my home directory as well, so I know this setup can work.

  Also, to be honest the last time I ran VOS on Solaris was maybe 3 years 
  ago.  I haven't had access to a Solaris box since then.  Also, at the 
  time I only had the server components running on Solaris, not the client 
  (due mainly because I only had ssh/remote X access and was not at the 
  console).
 
 Would it help to give an account on a Solaris/Sparc box? Of course, ssh 
 again.

It would help, except that right now my time is severly limited so I 
don't know when I would actually be able to do it.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] VOS on Solaris?

2007-04-25 Thread Peter Amstutz
On Wed, Apr 25, 2007 at 03:47:11PM -0400, Reed Hedges wrote:
 Lars O. Grobe wrote:
  Do you have libtool installed?  That is a separate package from autoconf 
  and automake.
  
  I compiled the most recent one from GNU. As I am not root, I installed 
  it in my home and added it to my PATH. Does the build make any 
  assumption where to find libtool (e.g. under /usr)?
 
 
 You may have seen Peter's recent message about changing the build
 system.  Pete, if we're not using automake, then we wouldn't have to use
 libtool either, right?

Please note that the discussion about alternate build systems is for s5 
only, I have no plans at this time to redo the s4 build system (although 
as a way of further evaluating build tools, I may apply them to building 
a part of s4 to see how they perform on real code and not a toy hello 
work project.)

Otherwise, yes, half the reason for ditching automake is to get rid of 
libtool.  Libtool has many quirks, a number of limitations (not 
supporting the MSVC compiler being the biggest one for us) and is 
ironically not abstract enough in a number of ways.  For example, it 
can't accept that DLLs on Windows don't have to start with lib and it 
doesn't understand how to build frameworks and app bundles on OS X.  
Despite being written to support portability, the portability libtool 
offers really only extends to classic Unix OSs.  So my preference is to 
switch to a build system with more modern sensibilities.

 Also, is jam is available on various systems like Solaris?

Yes.  Although the software I've seen that uses jam typically includes 
the jam source code in a tools directory, along with a shell script or 
batch script to bootstrap it (the script builds jam and then uses jam to 
build itself).

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Patches for 0.24 in MSVC

2007-04-25 Thread Peter Amstutz
Ok, I'm looking forward to looking over and merging this, looks like 
lots of good stuff, but I'm swamped right now so like your other email 
it will probably be a few days before I can get to it.

In the meantime Ken, if you're looking for something to do, I'd be very 
interested in your take on Jam vs Scons vs Cmake (see my earlier email 
for details) from the perspective of a mainly Windows developer.

On Tue, Apr 24, 2007 at 08:17:38AM -0700, Ken Taylor wrote:
 For your consideration,
 
 Attached are a bunch of patches for the code changes I made to get 0.24
 built and running with MSVC. I didn't include any of my changes to the
 vcproj/sln's -- just the codebase itself -- as those were a bit more on the
 hacky side. Some of these I think represent actual bugs, so I've marked them
 with **BUG**; others are portability issues that I've marked with **PORT**.
 Ones I've marked with **FIX** I think are solid fixes that I would suggest
 merging into the codebase, whereas others marked as **HACK** are hacky
 solutions that probably need a cleaner solution contrived for them. Unmarked
 ones you can take or leave, I guess
 
 I've tested building and running wxterangreal and omnivos in both MSVC and
 MinGW on windows with these fixes, using the demo project and also
 connecting to the world at interreality.org, and they seem to work across
 the board. Be aware, however, that I've only tested in debug mode -- no
 release builds yet.
 
 The only thing I haven't really tracked down is that avatar movement seems a
 bit jerky in the MSVC build. If I get more time I might look into it...
 
 Without further ado:
 
 vos:
   apps/omnivos/plugins/demoplugin.cc
- HAVE_UNISTD_H wrapper **PORT**
- for new_DoorBehavior and new_ChatBotBehavior **BUG?**
  - in case misc:clickable metaobject hasn't been added yet, add it.
  - this one is strange... it seems that on my computer, the XOD loader
doesn't add metaobjects to the class in the order specified in the
file, but rather in alphabetical order. So the demo: objects get
processed before the misc: objects, but unfortunately the demo
objects assume that misc:clickable exists, which caused crashing
for me. My solution was -- if it didn't exist yet -- check if the
object had the type, and if so, do an addType to get the
metaobject initialized. I'm not sure if your design intends
metaobjects to load in the order specified in the file, so I don't
know if this is the right fix or not.
- force port 80 on wikipedia.org **BUG** **HACK**
  - really the fix should be in the URL class, but I'm not sure
how much else in the codebase depends upon its current
behavior.
 
   apps/terangreal/ter_util.cc
- Terangreal::drawTextTexture: arrow only has 3 vertices, not 4. **BUG**
 **FIX**
 
   libs/vos/extensions/http/httpclient.cc
- define winsock2.h first, so it can exclude winsock.h **PORT**
  - winsock.h gets included somewhere later in the header chain,
but I didn't pin down where. Other options are to explicitly
exclude winsock.h ourselves, or I think defining
WIN32_LEAN_AND_MEAN works, but I didn't try it.
- use closesocket() instead of close() on windows **PORT** **FIX**
 
   libs/vos/vos/vosapp.cc
- HAVE_UNISTD_H wrapper **PORT**
 
   libs/vos/vutil/getaddrinfowrapper.cc
- #if 0'd out the custom versions of getaddrinfo, freeaddrinfo and
 getnameinfo **BUG** **HACK**
  - the custom code didn't work -- it crashed if hints was 0, and
didn't do any service lookup
  - note! for windows 2000, this will build using the MS SDK, but
not in MinGW!
 
   libs/vos/vutil/sleep.h
- put parenthesis around macro parameter extraction. **BUG** **FIX**
 
   libs/vos/vutil/snprintf.hh
- use _snprintf on win32 as well as mingw **PORT**
  - the custom snprintf had some bug in it that I didn't track down.
 
 
 crystalspace:
   include/csutil/win32/csconfig.h
- define CS_NO_NEW_OVERRIDE **HACK**
  - not sure what the best solution is. MSVC was just having
a hell of a time handling the new override with our code. I
think variables were getting created with the standard new
and deleted with the CS override new, which is bad.
 
   plugins/video/canvas/wxgl/GLWXDriver2D.cpp
- add SetFocus() to csGLCanvas::OnEnterWindow **BUG**
  - I'm not entirely happy with the default behavior to steal
focus whenever the cursor floats over the render view
(it can steal it from dialog boxes, etc) -- but apparently
this is how things were originally. I'm not sure what you
want to do with that code that broadcasts a focus event
to crystalspace.
 
 
 wxwidgets:
   include/wx/msw/setup.h
- define wxUSE_GLCANVAS to 1 **PORT** **FIX**
 
   src/msw/main.cpp
- change WXMAKINGDLL to WXMAKINGDLL_CORE **BUG** **FIX**
 
 Enjoy!
 
 -Ken

-- 
[   Peter Amstutz

Re: [vos-d] build system reviews (long)

2007-04-25 Thread Peter Amstutz
It's actually make distcheck that's interesting in this case.  In 
automake it gives you a single command that will build a source tarball, 
unpack it to another directory, runs configure and does a build.  It's a 
very useful automated sanity check on your source distribution.  Also 
make dist is distinguished from simply dumping your repository to a 
tar file by the fact that it includes certain generated scripts like 
configure that don't, strictly speaking, belong in your version 
control branch (since they're automatically generated from other files.)  
In the case of bakefile, this might include all the Makefile.in files 
produce by bakefile, that may or may not belong in the repository. [1]

[1] Although there is a case to be made that such files should be 
included in your repository anyway, since there are people who might 
want to check out the latest source for something but still don't want 
to be required to have every last little build tool.  Thoughts?

On Mon, Apr 23, 2007 at 06:17:38PM +, Lalo Martins wrote:
 I realise this is probably not the biggest con of scons (I guess that would be
 the slowness), but I'd be happy to write a make dist alike command and
 contribute it to upstream scons.  I wrote the similar thing for bzr, after 
 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.
-
 personal:http://lalo.hystericalraisins.net/
 technical:http://www.hystericalraisins.net/
 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

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Movement interpolation in csplugin

2007-04-24 Thread Peter Amstutz
Go for it.  Movement interpolation would be very nice :-)

So far as the SCF version goes, I think so long as you add the methods 
to the bottom of the class, don't modify parameters of existing and 
don't remove methods, it is considered a compatible change and you only 
have to bump up the minor version number.

On Tue, Apr 24, 2007 at 08:31:43AM -0700, Ken Taylor wrote:
 Hey All,
 
 I think I've worked out a good way to have csplugin interpolate between
 position updates, and I might start working on implementing it over the next
 week or so. I just had a couple questions:
 
 1) would this step on the work anyone else is doing at the moment (or is
 there some other reason that you would suggest against me doing this)?
 
 2) I want to add some functions to the csplugin interface (to turn
 interpolation on and off, set its parameters, etc) -- Do y'all have a scheme
 for setting the SCF_VERSION numbers when the interface changes? I think I
 remember reading in the CS manual that adding functions at the end of the
 class will allow backwards-compatibility, and that certain version numbers
 are considered by SCF to be backwards compatible, so I'll make sure to stay
 consistent with that, at least.
 
 In a few days, I may send a message to this list detailing the changes I'm
 planning on making to the code, to see if there's any comments.
 
 -Ken
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 scripting (design part 3)

2007-04-24 Thread Peter Amstutz
I just wanted to say, these are really good questions and deserve 
substantial answers and discussion.  I'm planning on answering properly 
when I find the time (a thorough reply will take awhile to compose.)

On Sun, Apr 22, 2007 at 02:18:31PM -0700, Ken Taylor wrote:
 So, from a user's perspective, how might the following cases work in an
 Interreality 3D system built upon vos s5:
 
 1) Someone running a server wants special behavior from an object, written
 in the scripting language of their choice, to be attached to an object at
 run-time -- but without that code being accessible to clients.
 2) Someone connecting to a server with a client owns a bit of 3d space and
 can create objects and attach scripts to them. They create a new object with
 some sort of behavior, and they upload the script to that object. What if
 the script had a syntax error? What if the script tried to do something
 illegal or use up too many resources?
 3) Someone wants to write a script for their vos-based client that just
 tweaks the interface client-side (perhaps automating some functions or
 creating new UI elements). What if they wanted this script to break out of
 the typical sandbox?
 4) An object on the server contains a script to be run client-side, perhaps
 to perform some special animation effect or to support some custom
 interaction with the server, and the user of the client can decide to accept
 that script or not.
 
 Also: will interreality specify any default languages to be supported as a
 baseline, or will it just be whatever runtimes the current server has
 installed? Will there be a way to query the server for what runtimes it
 supports, and what capabilities those runtimes have? Can an object (such as
 in case 4) have multiple languages attached to it, so the client can pick
 which one it supports the best? Can a script specify at the outset what
 capabilities it requires so the vos kernel can decide whether or not to even
 run it (or to ask the user to allow certain capabilities)?
 
 -Ken
 
 ps: Something else that may be interesting -- having a special VOS
 translation layer that lets one run scripts wrtten for VRML nodes in a VOS
 world. This could facilitate importing VRML files transparently.
 
 Peter Amstutz wrote:
  Third in a four part series on major design changes in s5
  (What could also be called VOS Apocalypse)
 
  Scripting.
 
  One of the things we have encountered over the course of our open source
  efforts was (obvious in retrospect) people don't like dealing with C++.
  While there remain compelling reasons to write the VOS kernel in C++,
  for most people the language is hard, setting up a compilation
  environment is difficult, and there are many things a statically
  compiled language simply can't do, such as evaluating new code on the
  fly.
 
  With s3 and s4, we have tried to address scripting using the Simplified
  Wrapper and Interface Generator (SWIG), which is an excelent program
  which can read C and C++ header files and produce bindings into a
  variety of popular programming languages.  However, this approach
  suffers from a flaw: by design it is oriented towards calling C/C++ code
  from other languages.  It does not, however, provide much support for
  allowing your C/C++ code (or other languages hosting in the same system)
  to call back to that scripting code.  So, scripting languages are
  second-class citizens.
 
  What I intend to do in s5 is see to it that all programming languages
  (scripting or otherwise) can be a first-class citizen in VOS, so that C,
  C++, Perl, Python, LISP, Java, C# etc code can all call each other,
  agreeing on the same APIs and data types.  The goal, is to allow users
  to write behaviors and extensions for VOS in their programming language
  of choice.
 
  This is, in some ways, one of the holy grails of computing.  How many
  times has a project been rewritten, or required redundant work, because
  software A in one language needed to link with software B in another?
  Now, I don't want to overstate what we're doing, but I do believe that
  certain key aspects of VOS enable us to produce a cleaner solution than
  the existing state of the art.
 
  There are three key design elements:
 
  1. Actor model for Vobjects and message passing.
 
  This is shakes out from the concurrency design discussed earlier.
  Because Vobjects are required to communicate via message passing, it is
  easy to add a translation step that converts message parameters from one
  language datatypes to another.  Datatypes will consists of either
  copyable primitives, or Vobjects, so object references that are
  communicated between languages are independent identifiers not tied to
  particular memory (or network) location.  Capabilities can be used to
  enforce security between runtimes (more on that later).  Finally, and
  most importantly, there is no inversion of control inherent when calling
  on a vobject that is handled by another language.  This means

[vos-d] Lindens opening up the Second Life server

2007-04-20 Thread Peter Amstutz
Linden Labs has made another statement that they will soon opening up 
the server.  Not a suprise, but has touched off another wave of 
speculation about where they're going with it:

http://www.3pointd.com/20070328/platforms-and-technologies-panel-at-vw07/

People have pointed out that a number of technologies SL depends on are 
themselves proprietary (such as the Havoc physics engine) so whatever 
they release is probably not going to be 100% free software.

I think that the strength of VOS going forward (particularly embodied in 
the new design) will be the ability for the object model to interoperate 
with other systems on their own terms, so we can still play to the 
strengths of VOS on either the frontend or backend (depending on the 
application).

The big players in virtual worlds are starting to emerge, but it is 
still early in the race, and we're in it for the long haul...

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] s5 scripting (design part 3)

2007-04-20 Thread Peter Amstutz
, very common in VOS 
-- for example a typical avatar has at minimum types misc:avatar, 
a3dl:object3d.model, a3dl:actor and misc:talkative) which could now in 
s5 be potentially implemented is multiple languages.  This mashup 
capability is very powerful and fairly unique to VOS (I think you could 
probably do it in Croquet due to its Smalltalk basis, but that's about 
it).

This flexibilily also means applications are free to attach 
application-specific data to vobjects that will be ignored by tools that 
don't recognize it.  For example, a file format loader for some 3D scene 
could package up the parts it doesn't understand and include them along 
with the parts that have been converted to standard A3DL data.  When 
exporting that same scene back to the original file format, those parts 
can be retrieved and output again to yield the identical original file, 
rather than those parts having been stripped off and lost in the 
original loading.

VOS also provides reflection (OTDs will themselves be represented in the 
system as vobjects, essentially metaclasses).  For example, iterating 
over child vobjects is very similar to iterating over the fields of a 
class.  Vobject structures can be navigated and manipulated using 
generic tools, and scripts which process Vobjects can be simpler and 
require fewer assumptions about the underlying objects.


The big picture of what I'm trying to do with s5 is make VOS an 
object-oriented programming infrastructure that ties together all of 
computing, and happens to makes the end goal of an immersive, 
collaborative 3D world really easy to implement.  The reason is that I 
want to be able to leverage other people's work in programming 
languages, operating systems, databases and graphics in a way that is 
easy and effective.  This is the basic motivation for defining VOS as a 
platform: so in the long run, we don't have to do all the work.  So 
instead of stitching together a half-assed 3D engine, a half-assed 
database and a half-assed scripting language all created in-house, we 
can create a best-of-breed system that ties together the best of each 
category.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] S5 and single-thread option

2007-04-20 Thread Peter Amstutz
On Fri, Apr 20, 2007 at 01:52:39PM -0400, Reed Hedges wrote:
 
 Pete, in your description of S5 so far it seems like it is defining a
 threading model that is not neccesarily coupled to a particular thread
 implementation. That is, conceptually vobjects are threads or proceses
 but I am guessing that you won't be implementing it by simply creating a
 pthread for each vobject :)   Does this mean that it will use a thread
 pool of some kind?   If so, would it be possible to have a thread pool
 of size 1, thereby making it possible to run VOS on an OS that
 effectively has no threads (I'm thinking of stuff like handheld devices,
 phones, embedded systems, whatever).

Yes, actually one of my goals is to ensure that the system could be run 
in a single-threaded mode to be useful for applications like discrete 
event simulation.  For network code we're likely to want to have at 
least one thread that handles socket activity, but if necessary that 
could also be something that gets called periodically from the toplevel 
event loop.  Obviously I would like to avoid the recursive-runloop 
stategy employed by s3, so this will require that all behaviors are 
written using continuations so that if they have to wait, we can unwind 
the stack and control can be returned to the top level.

But normally there would be a thread pool.  Ideally, most of the time 
most vobjects are unbound which means they arn't running on any 
thread.  Vobjects might even be swapped out to the persistance database 
if they arn't being used.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] URL::parse problem

2007-04-19 Thread Peter Amstutz
Actually, I'm pretty sure the HTTP_GET() function ignores the port on 
the URL object and asks to connect to the http port (which should be 
looked up in /etc/services).  Perhaps that should just specify port 80 
explicitly.

But you're right, the VOS URL class is highly VOS-specific in 
specifying 4231 as a default, which is kind of silly.

On Wed, Apr 18, 2007 at 10:55:44PM -0700, Ken Taylor wrote:
 So I tracked down one of the problems I'm having with the wikipedia demo
 object: It's trying to connect to http://en.wikipedia.org:4231/ -- turns out
 if you give the URL parser a URL without a port, it will add 4321 as the
 port!  That seems kinda silly to me, since default port is a
 protocol-specific thing. I'm surprised this has worked for you (assuming
 you've been using it as is) -- oh well, I'll just force it to :80 in the
 wikipedia object and see how it goes from there.
 
 -Ken
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Integration of VOS and IRC

2007-04-18 Thread Peter Amstutz
To be honest this is not something we have time to work on, but if you'd 
like to pick it up we'll be happy to help you get up to speed.

You might also want to look at the mesh utility in the VOS 
distribution, which is an interactive command-line shell that presents a 
textual interface to the underlying VOS data structures using a unix 
file system metaphor.  It's not semantic (as we're discussing here) but 
it may be an interesting starting point, and is effectively the current 
textual portal to VOS.  It's quite powerful (much more powerful than 
the 3D GUI, at the moment).

On Wed, Apr 18, 2007 at 11:16:43AM +0100, Marcos Marado wrote:
 On Wednesday 18 April 2007 09:26, Karsten Otto wrote:
  Am 17.04.2007 um 19:54 schrieb Peter Amstutz:
   [...]
   Also something I've wanted to explore is the possibility of creating a
   semantic representation of a space that is meaningful enough to be
   navigated from both a MUD-style text interface, while still being able
   to enter it as a fully 3D immersive world.
 
  Interesting idea, and somewhat close to my current field of work.
 
 Great, I was looking for something like that for years now :-) 
 
 I think that this is something really interesting, and that should not 
 only be discussed, but implemented. It would be nice that, by default, 
 a VOS instalation came with the choice of having both graphical and 
 textual entrances to it. Furthermore, it would be nice if the 
 textual portal was MUD-like, maybe with a telnet and a telnet-ssl 
 port opened for connections.
 
 I'm new to VOS, so I guess I can't yet be really useful here, but I'll 
 try to help as I can...
 
 Best regards,
 -- 
 Marcos Marado
 Sonaecom IT
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Thinking about Javascript

2007-04-18 Thread Peter Amstutz
Well, one approach would be to treat HTTP as an unreliable/stateless 
channel, implement stateful, connection-oriented sessions on top of 
that, and then have VOS (both on the server side and in the browser) run 
on that layer.  So then it would easy to push updates to the browser by 
queuing messages until the next time the browser checks in.

On Wed, Apr 18, 2007 at 11:39:06AM -0400, Reed Hedges wrote:

 Yeah, this is why I was looking for libraries out there that address
 these things (so we wouldn't have to).  So far I'm only aware of comet
 and dojo (dojotoolkit.com) (the client side).
 
 Probably the best thing is to focus on just updating HTML in the
 browser. So if the browser opens that persistent, listening channel,
 then Hypervos can listen to the Vobjcets on its behalf, and if it e.g. 
 sees a child-inserted and the new object is HTML/XML, and it also has 
 an open connection to a listening web browser, to serialize the new 
 objects into an HTML fragment and push that to the browser.   
 Similar for anything changing in the objects or something removed.
 stick the new or changed HTML into the DOM (set innerHTML or something).
 
 Anyway, I'm just trying to gather ideas for future web applications, I
 probably can't work on this right away-- but if you want to that would
 be great, let me know and we can coordinate.  I've been gathering these
 ideas at http://interreality.org/wiki/HyperVosIdeas . Part of my
 motivation has been searching for a good web application focused on
 Question and Answer customer support, as well as general forum
 discussion.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] VOP patches for 0.23.0

2007-04-17 Thread Peter Amstutz
Great, I'll take a look at these and see if it still applies to 0.24.

On Tue, Apr 17, 2007 at 11:24:58AM +0200, Karsten Otto wrote:
 Hi again,
 
 while I am at it, I thought I'd send the patches I am currently using  
 to switch VOS back to the VOP protocol. For most applications (in  
 particular mesh and omnivos) you can use the flag --proto=vop, but  
 some do not support it (in particular the CS plugin, wxterangreal,  
 and a3dldemo).
 
 Btw. the a3dldemo patch also fixes a number of permission problems,  
 which would occur even if you used it with VIP.
 
 Enjoy!
 
 Karsten Otto (kao)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Terangreal crash

2007-04-17 Thread Peter Amstutz
On Tue, Apr 17, 2007 at 11:00:09AM +0200, Karsten Otto wrote:
 Hi all,
 
 Reading about Trer'angreal crashing or hanging, I just recently  
 discovered a small bug in the message handling of the 0.23.0 release.  
 Of course this is regarding the VOP protocol, which probably nobody  
 except me uses anymore, so I am not sure anybody else is affected :-)
 
 During normal operation wxterangreal sometimes came to a screeching  
 halt with the obscure error message Remote site error: Protocol  
 violation: negative number attribute
 
 I tracked this down to libs/vos/vos/ 
 messageblock.cc:XmlParser::parseNumberAttr,
 which basically does this:
 
 int res = (int)strtoul(start+pos+1, end, 10);
 if (res  0) throw ProtocolError(...)

 [snip]

 Is the range check actually necessary in this method? I don't have  
 the time to track this down...

You're right.  I'm an idiot.  The variable res should be an unsigned 
int, and the range check is unnecessary.  I have no idea why that code 
is there, and I'll take it out.
 
 Despite of this obvious bug, I am pleased to see that VOP still sort  
 of works despite the long neglect :-)

I'm glad it's been useful to you.  It's also proven to us the value of 
supporting multiple protocols that focus on different aspects like 
performance or ease of interoperability -- hopefully s5 will finally 
support multiple protocols within a single session :-)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Got wxTerangreal to build in MSVC++!

2007-04-17 Thread Peter Amstutz
On Mon, Apr 16, 2007 at 11:34:40PM -0700, Ken Taylor wrote:
 Woo!
 
 It's been an epic adventure, but I'm successfully running wxterangreal built
 from scratch (and boost, wxwidgets, and CS built from scratch, too) through
 Visual C++. And I should still be able to build with mingw, as well, so I
 can verify any changes against the two different build systems
 simultaneously.

Wow, that's great!  I don't think I've had ter'angreal 100% working in 
MSVC for a long, long time.

 At some point after the dust clears I'll have to sort through all my mad
 hacking and figure out what I actually did to make it work... actually it
 wasn't quite that bad. But there were a few interesting things along the
 way, such as:
 - A bug in wxwidgets' msw/main.cpp where it used WXMAKINGDLL instead of
 WXMAKINGDLL_CORE (I'm guessing they've fixed this by now)

Well that sucks.  We have our own wxwidgets branch so we can fix that, 
though.

 - Adding CS_NO_NEW_OVERRIDE to the CS setup file -- their special debugging
 new/delete stuff was just causing too much trouble and I didn't want to
 figure out exactly why.

That's fine, we arn't going to use their memory debugging anyhow.

 - having to track down a weird bug in object movement that seemed to have
 something to do with snprintf...
 
 That last one is worth talking about here -- my avatar movement was all
 wonky. But now that i have an IDE debugger that actually works decently, I
 was able to trace the problem to snprintf printing the floats wrong for
 position/oritentation in the 3dobject properties in some cases. It was using
 the custom snprintf function, but I didn't actually identify where in that
 function the problem lay. Instead I just went ahead and made it use
 _snprintf (just like MinGW)... is there any particular reason not to use
 _snprintf? The microsoft headers define it...

Uh.  Yea, I don't know why I did that, aside from the fact that fighting 
with Microsoft's idea of what is and is not in the standard library is 
an endless source of frustration.  We should probably have just used 
#define snprintf _snprintf, then?

 Anyway, just throught you'd be interested. I haven't tried building the new
 demo server yet, but when I do I'll see if I can track down that crashing
 bug (unless it's been fixed). I did go ahead and walk around the new gallery
 COD in local-file mode in terangreal, and it's pretty spiffy. The solid
 camera, even as simple as it is, is a nice addition, too. Oh, and grabbing
 things is fun :)
 
 (However, I can't actually log in to the interreality server at the
 moment... )

I need to pull out the ircbridge plugin from the interreality.org 
configuration until I can figure out why it's causing the server to 
deadlock.  What's irritating is I haven't been able to get a stack trace 
that will tell me exactly where the two deadlocked threads are getting 
stuck, so it's been exceedingly hard to debug.

(I'll do that right now, so by the time you get this message the world 
should be back online.)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Integration of VOS and IRC

2007-04-17 Thread Peter Amstutz
Yes, the IRC plugin is included as part of the distribution by default.  
It creates a VOS user for each IRC user in the virtual world, and 
creates a separate IRC client session for each user in the VOS world, so 
it is completely transparent.

Currently IRC users in VOS arn't given any form, but there's no reason 
why they couldn't be given avatars and placed somewhere on the map (I 
someone suggested having them wander around aimlessly, like the 
townspeople in certain console RPGs :-)

Also something I've wanted to explore is the possibility of creating a 
semantic representation of a space that is meaningful enough to be 
navigated from both a MUD-style text interface, while still being able 
to enter it as a fully 3D immersive world.  You could lay down a node 
network of positions where the text-user could go, add descriptions to 
all the objects in the space, and then at each node it would print out 
the descriptions for things that were nearby.  For example (thinking of 
the current demo black sun world:

---
You are standing on a hill of brown dirt.  To the north is a large 
white pyramid with an entraceway.  To the east the hill continues.  To 
the west the hill continues.  To the south is black nothingness.

$ Go north

You are at the entrace to the Pyramid.  To the north is a hallway with 
a tiled floor.  At the end of the hallway are ramps leading up and to 
the east and west.  To west is a doorway.

$ Go north

You are at the end of the hallway.  To the south is the entrance to the 
Pyramid.  To the west is a doorway.  Up and to the east is a ramp.  Up 
and to the west is a ramp.
Gonzo is here.

Gonzo(3d) says Hello!

Gonzo(3d) goes south to the entrace to the Pyramid.

You see Gonzo(3d) by the entrace to the Pyramid.

Gonzo(3d) waves to you.

$ 
---

And so forth...

On Tue, Apr 17, 2007 at 04:54:36PM +0100, Marcos Marado wrote:
 
 Hi there, 
 I said this on your IRC channel...
 -
 
 * Now talking on #vos
 * Topic for #vos is: Virtual Object System :: http:://interreality.org :: 
 Free 
 Multi-user Virtual Reality
 * Topic for #vos set by tetron|mac at Tue Dec 12 04:28:20 2006
 * #vos :[freenode-info] why register and identify? your IRC nick is how 
 people 
 know you. http://freenode.net/faq.shtml#nicksetup
 Mind_Booster_Noo hi there
 * You are now known as Mind_Booster
 Mind_Booster I saw your website...
 Mind_Booster I wonder, does the VOS server already comes with this plugin 
 to interconnect a world with IRC?
 Mind_Booster I'm a talker owner (for those now knowing, a talker is a 
 text-based virtual world) and it would be great to be able to connect it to a 
 graphical world like VOS
 Mind_Booster keeping both interfaces, the via telnet text-based world and 
 the vos-browser...
 Mind_Booster hmm, I guess you're all asleep :-P
 Mind_Booster I guess I'll email this question to the mailing list :-)
 Mind_Booster thanks anyway, and keep up with the effort :-)
 
 -
 Can anyone please give me an answer? I would really be interested in this.
 
 -- 
 Marcos Marado
 Sonaecom IT
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 concurrency (design part 2)

2007-04-12 Thread Peter Amstutz
On Thu, Apr 12, 2007 at 10:41:40AM +0200, Karsten Otto wrote:

 I thought that the coroutine stuff applied trusted code only -  
 after all, when you cross the border to untrusted code, you have to  
 pass control over to whatever virtual machine executes it, and hope  
 for the best. In the most general case, this virtual machine might  
 use a different threading model or may not even *have* threads (shell  
 script?). Changing arbitrary kinds of script code on the fly is bound  
 to be difficult, error prone and time consuming. Modifying all VMs to  
 support context switching is even more unrealistic. Usually people  
 only have a standard perl/python/lua/xyz installation. LL has the  
 advantage that people only use ONE scripting language, running on ONE  
 VM - under their control.

The point of the Second Life example was that it has been shown in 
practice that it's possible to implement cooperative multitasking in a 
way that still doesn't allow unscrupulous users to hang the system (at 
least not with naive attacks like going into an infinite loop).  This is 
important, because preemptive multitasking is difficult and generally 
non-portable to implement in userspace; it is the job of the underlying 
operating system to provide multitasking facilities (processes, 
threading).  The problem for VOS is that these facilities are probably 
too heavyweight for the number of simultaneously executing actors that 
we want to be able to scale up to support.

In the case of LSL I believe that the client compiles the scripts 
locally and just uploads the bytecodes.  It uses the CLI run on the .NET 
virtual machine, and they've been making noises about supporting C# 
(although it may be that LSL uses a restricted subset of codes that are 
easier to verify, which would not be the case for C#).  So they are 
doing static analysis and modification on the actual bytecodes to be 
run.

So you're right, it requires targeting a specific virtual machine 
platform, but there's nothing wrong with that.  I'm not suggesting this 
for scripting in general, but for the particular case of mobile code 
(downloaded to the client or uploaded to the server and executed 
automatically) where it is necessaray to provide a constrained, secure 
environment.  A pretty fundamental aspect of security is not being able 
to hijack the host application's computation.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
[EMAIL PROTECTED]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 concurrency (design part 2)

2007-04-12 Thread Peter Amstutz
On Thu, Apr 12, 2007 at 08:13:19AM -0400, Reed Hedges wrote:

 OK. (You could use VOS easily to do flow based programming, I think 
 there's a brief note about this in the wiki somewhere.)

Yes, of course.  I think the actor model is much more general-purpose, 
at least in so far as it seems much simpler to describe flow-based 
programming using actors than to describe actors using flow-based 
programming.

 I was under the impression that an Actor was a function that did just 
 one thing? Or are there variations on the model?

Did you read the Wikipedia article?  An actor is an independent 
concurrent entity which can exchange messages with other actors, create 
new actors, and designate the behavior for each message received.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
[EMAIL PROTECTED]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] terangreal changes

2007-04-12 Thread Peter Amstutz
This is mostly directed at Reed, but I thought everyone might be 
interested --

In working on a virtual demo world/presentation (which I intend to use 
as a more compelling alterative to openoffice impress slides in 
presenting VOS to potential investors) I've made a few changes that make 
worldbuilding much easier:

 - Fixed bugs in blender export script which causes rotations to 
sometimes come out wrong.

 - Added an addtype directive under the load section in XOD files, 
so objects from loaded files can be extended.

 - Added some code to the vosapp framework so that if plugins introduce 
new metaobject factories, existing vobjects with that type will have 
metaobjects automatically attached.

 - Fixed some collision handling in the CS plugin that was misbehaving.

 - The 3rd person chase camera now won't go through walls, but will zoom 
in as necessary to have a clear line of sight to the avatar.

 - If you can hit g while moused over a 3d object, you grab it, this 
means the object is placed in front of you and moves around when you 
move.  (Moving this with the mouse isn't supported yet.)  You can tag 
this a3dl:nograb to tell ter'angreal not to grab them (useful to avoid 
grabbing the floor or walls by accident.)

So, in combination with the new misc:clickable and misc:textentry types 
(which communicate clicks on prompt for text on 3D objects) it's now 
relatively easy to add behaviors (written in C++) to 3D objects in 
scenes created in Blender.  See galley.xod in vos/apps/omnivos/ for 
the work in progress.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
[EMAIL PROTECTED]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 concurrency (design part 2)

2007-04-12 Thread Peter Amstutz
On Thu, Apr 12, 2007 at 08:56:12PM -0400, Reed Hedges wrote:

 Will messages be like they are now, essentially a map? Or could we have 
 a Message subclass generated from the OTD, with pointers into the 
 message data for each field, so we don't have to look up fields by name 
 each time?

We could do that, although actually as implemented in the current s5, 
the fields are converted into arguments to a method, so the user doesn't 
see the actual message structure, just gets a method call with the 
fields as parameters.  This is why type conversion to the expected 
method signature is important.

 Yeah, it would be nice not to have to do too much processing on the 
 Message object to send it out over the network-- just grab a data buffer 
 out of the object and byteswap it (or not).

Some processing is necessary if messages are to remain abstracted from 
the concrete serialization format.  In particular, it ought to be 
possible to convert a VOS message to both a lightweight binary format or 
to something like SOAP or XML-RPC for interoperating with 3rd party 
systems.  That's where having both a binary encoding and ASCII encoding 
for primitive types comes into play.

 One thing that would be nice in s5 is to be able to very easily nest 
 message structures, either through just embedding a second message 
 inside another as a field, or by a struct definition in the OTD and 
 putting struct type data in the message.

Actually s5 has structs already!  As it stands now it is fairly weak 
(only combinations of primitive datatypes or other structs allowed, no 
recursive nesting, no dynamic-sized arrays) but I certainly agree that 
structs are useful.

Here's some testing code in the current s5 interface.  This is real 
interface code which can be processed by the code generator:

interfaces
 namespace name=a3dl
struct name=vector3
  field name=x type=float /
  field name=y type=float /
  field name=z type=float /
/struct

struct name=rotation
  field name=axis type=vector3 /
  field name=angle type=float /
/struct

class name=object3d
  child name=position type=vector3 /
  child name=orientation type=rotation /
  child name=transform-group
child type=object3d count=any /
  /child
/class
 /namespace

  namespace name=misc
class name=talkative
  child name=relay-listeners
child type=talkative count=any /
  /child

  method name=say
param name=text type=string /
param name=scope type=uint16 /
param name=priority type=uint8 /
param name=in-reply-to type=uint32 /
  /method

  method name=resend
param name=resendTo type=vobject /
param name=text type=string /
param name=scope type=uint16 /
param name=priority type=uint8 /
param name=in-reply-to type=uint32 /
  /method
/class
  /namespace
/interfaces

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
[EMAIL PROTECTED]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 concurrency (design part 2)

2007-04-11 Thread Peter Amstutz
On Wed, Apr 11, 2007 at 06:20:21PM +0200, Karsten Otto wrote:

 Ok, I get it. What you say sounds exactly like the Simula coroutine  
 concept, where you use an exchange jump to switch between multiple  
 stacks. This is not necessarily the same as user-level threads, in  
 particular when blocking I/O is involved.

You're right, it's a bit different from user threads, although what I 
have in mind could be handled reasonably well by creating a user thread 
for every vobject ahead of time.  Then a sending a message would involve 
more or less pushing the call into the target's message queue and then 
explicitly yielding to the target.

However, I realized after writing the email that that any solution which 
results in blocking the sender due to the target blocking isn't the 
right behavior.  The sender may be able to handle the message as an 
asynchronous call (since it gets a future back) so it's not fair to 
block it -- indeed that's the whole point of being able to switch tasks.

So, we want to be able to save state and return to the immediate caller 
(not the toplevel event loop, as I said in my previous email).  
Unfortunately the unix swapcontext() isn't really appropriate in this 
case, because it saves the entire stack (which includes the caller's 
stack, and caller's caller's stack, etc...) and we're really only 
interested in just the stack for the current vobject.

 Digging around a bit I found http://en.wikipedia.org/wiki/Coroutine
 which explains this nicely, lists a few libraries, and even mentions  
 the Actor model (duh) :-)
 You probably know this page already, but I thought I'd mention it  
 anyway just in case.

On further research, I'm coming around to the conclusion that there 
simply doesn't exist a good implementation of coroutines or user threads 
in C/C++.

So I think a futures-based, continuation-passing style is going to be 
the way to go, with blocking waits not permitted.  Instead, we'll focus 
on the more tractable goal of providing a good API for 
psudeo-continuations in C/C++ (boost may be helpful here) as well as 
hopefully ensuring that design allows bindings for lanaguages that do 
have coroutines/continuations can take advantage of it.

I should also note that the other side of this is that a method can be 
marked CPU_INTENSIVE or BLOCKING, which will cause VOS to always 
execute the method in a different thread from the sender.  The goal of 
all of this is that, since we will be doing message passing internally 
to the application and as well as across language/network boundaries, to 
be efficient and avoid context switch overhead when the method being 
called is trivial.

On a related note, I started thinking a lot about user 
threads/microthreading/continuations etc in part from reading a couple 
of developer blog entries on how Linden Labs acomplished it in their 
server.  They have an interesting challenge (which we will eventually 
also have to deal with) which is that they need to support many 
thousands of scripts running simultaneously on a simulator, and the 
scripts come from untrusted sources that can do obnoxious things like 
spin in an infinite loop and never return.  Operating system threads 
arn't suitable due to overhead (and possibly also due to synchronization 
requirements with the physics simulation) so it has to be a user-level 
thread strategy.  However, users can't be trusted to have their code 
ever yield (or even ever end).  So, they force the issue.  The scripts 
are compiled for the .NET virtual machine, but before they are allowed 
to run, a gatekeeper inserts explicit yields into the bytecode at 
strategic points (branching points being the obvious target, if I had to 
guess).  This results in each script periodically checking to see if it 
has run out its timeslice, and when that happens it explicit yields to 
the next thread without the need for preemptive scheduling.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 concurrency (design part 2)

2007-04-10 Thread Peter Amstutz
On Tue, Apr 10, 2007 at 10:52:33AM +0200, Karsten Otto wrote:
 Ok, I haven't studied this Actor model so far, let me see if I  
 understood it correctly.

Note that what I'm proposing here is an elaboration on the model -- a 
literal implementation of the model would put each actor in a separate 
*process* and compel all communication over sockets (this would enforce 
the no-shared-state aspect of actors).  However, even on modern 
operating systems, having 10,000 vobjects as 10,000 separate processes 
is not going to be efficient, so we need to allow the implementation to 
take shortcuts.

 If a message comes in from the network, you determine its target  
 vobject and method(?). You then try to bind/lock the target, and  
 execute its method in a thread you pick from a pool. If the vobject  
 is already bound, you just queue the message for later execution.  
 Once the vobject gets unbound/unlocked, you pick another thread from  
 the pool and pass the queued message to the target method. (Actually,  
 it does not matter whether the message came from the network or some  
 other actor, which is neat).

Right.  The goal is to unify message passing so that it genuinely does 
not matter if a vobject is local or remote or native code or a script.  
I'd also like to support transparent process migration, so that a 
vobject could move to another host and have its messages forwarded to 
it.  The trick is support all this AND still be efficient and easy to 
use.

 While a vobject method is executing, it can send messages to other  
 vobjects, which either bind and execute the target *in the same  
 thread* or queue a message, as before. In the latter case, you get a  
 future you can query for completion or wait on.

The purpose of allowing execution within the same thread (when the 
target vobject is unbound) is that usually the actual method handler 
code that needs to be executed is either small and quick to execute, or 
the caller is likely to block anyway (in the case of reading a property) 
so there is less overhead if we just service the request immediately.

For the cases where a call is likely to start a long-running process, it 
is the responsibility of the programmer (of the method handler 
implementation, not the caller) to mark these methods as such so the 
system knows to spin them off into a separate thread.

 Assuming I got it right so far, I wonder what happens if you decide  
 to wait on your future. When you do this, you block the current  
 thread, which nevertheless still holds the locks of  / is still bound  
 to one or more vobjects. In other words, the deadlock just waits  
 around the corner - e.g. two vobjects with separate threads and  
 futures for each other. Or does waiting automatically release the  
 blocks/bindings? In that case, what happens once the thread unblocks?  
 And can another thread bind/lock the vobject in the meantime?

This is a good point; blocking makes everything more difficult and when 
I was writing about it originally hesitant to include it at all.  Now I 
see my instinct was correct.  The two solutions I see are:

 - Disallow blocking, and require a continuation passing style where 
futures+callbacks are chained together and returned up the stack to the 
main event loop, at which point it is added to the scheduler to be 
executed when the commitment is either satisfied or fails.  

 - User-level threading on top of OS threads.  A blocking call would 
save the stack and return to the main event loop (using swapcontext() or 
the Windows equivalent), at which point the (user-level) thread is added 
to the scheduler to be resumed when the commitment is either satisfied 
or fails.  If this sounds similar to the first case, that's because it 
is.  The key difference here is that it requires less work on the part 
of the user (less boilerplate, code doesn't have to be split up across 
methods).  The disadvantage is that users may be less aware of what is 
going on, and that other methods could be called while their handler is 
blocked.

In either case, when a vobject chooses to wait for a result, that 
vobject and all the vobjects in its call stack would be permitted to 
service other requests.  This solves the problem you present: the 2nd 
vobject in the 2nd thread is eventually able to call the 1st vobject, 
because the 1st vobject has yielded control and can handle new requests.

I should also note these two options arn't incompatible, so there's 
likely no reason we can't have both continuations and user-level 
threads.  My preference is towards cooperative threads, however, 
unfortunately portability is going to be difficult as Linux, Windows and 
OS X all seem to use different APIs for this.  I haven't yet found a 
library that abstracts it across operating systems in the same way that 
has been done for OS threads.  Most portable user-level thread 
libraries I have found actually use setjmp/longjmp, which doesn't 
preserve the stack.

-- 
[   Peter Amstutz

Re: [vos-d] s5 concurrency (design part 2)

2007-04-09 Thread Peter Amstutz
On Fri, Apr 06, 2007 at 05:16:16PM -0400, Reed Hedges wrote:

 There's also something called Flow-Based Programming that is similar. In
 some ways it's closer to VOS since Actors are, I think, more like method
 handlers (in VOS terminology). 

I don't agree.  Flow-based programming is very data-centric, in the 
sense that it views the system as a connected chain of inputs and 
outputs and black boxes doing transformations.  This is a good fit for 
certain kinds of data processing where data is streamed through a 
multistage system (audio/video processsing, certain types of batch 
processing) but isn't as useful for interactive systems.  If each box in 
a flow programming system is a vobject, and a connection between boxes 
means sending a message between vobjects, VOS starts out with the 
assumption that every box is potentially connected to every other box.  
At that point the flow model isn't particularly useful.

VOS grew out of my work in multiagent systems, and it's pretty well 
understood in that field that agents act independently of one another 
and their communication/coordination is asynchronous.  Thus, the idea 
that vobjects == actors seems like a natural fit.  You could say that 
the actor model is a design pattern that we happened to stumble upon, 
and that by recognizing it as such we can take advantage of the existing 
work on the topic.

 But Actors Model is more well known and more carefully studied and
 defined (though I guess we will be deviating from it)

Well, it's a model, not a precise specification.  The basic goal here is 
to define how flow-of-control works in a concurrent VOS application, in 
a way that is easy for users to grasp and prevents deadlocks and race 
conditions.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] misc:search questions

2007-04-09 Thread Peter Amstutz
On Sat, Apr 07, 2007 at 04:56:53PM -0700, Ken Taylor wrote:
 So my voyages through the VOS codebase have brought me to the misc:search
 metaobject. It's a pretty nifty metaobject, really... but i have some
 questions/comments:
 
 - It looks like when you acquire an object, some times it will also
 acquire all that object's children. I'm specifically looking at the
 CatchUpdatesFilter::savechildren value. But I don't quite understand in what
 cases this gets set and what the rationale is for getting the children. All
 the message filtering stuff makes the code a bit hard to understand, because
 the filters happen in the background and change the normal behavior of the
 VOS system... the fact that you guys seem to be allergic to comments doesn't
 help either ;) (i jest! i jest ... sorta)

The basic theory behind the search metaobject is that it has a 
pattern-matching state machine that walks the vobject tree, synthesizes 
queries to each vobject, and catches the responses (hence the filter).  
The responses are the packed into a COD, gzipped, and that is 
transmitted to the client which does the process in reverse.  This is 
what allows VOS to have a fine-grained representation of the world yet 
still download it relatively quickly and efficiently.

That said, I haven't decided whether to keep it for s5 or do something 
else that might be simpler.  It's arguably overkill, and the complexity 
means it may be hard to optimize.  Also it needs to accomodate some 
design for caching, where the client might send a set of hash codes 
describing its cached data, and the search object has to be smart enough 
to only send the parts that have changed.

 (man, i'm just a complainer, aren't i?)

Reed is right, I don't comment my code enough.  I'll try to be better 
about it in the future, especially since I know more people are looking 
over my shoulder now.

Also: you should be REALLY thankful you didn't see the first version of 
the search metaobject :-)

 - Could it be possible for there to be a malicious or just buggy
 infinite-loop query that messes up the server (since incoming update
 messages are being deferred during a query), or is it guaranteed to
 terminate?

As each vobject is visted, a temporary flag is set to prevent it from 
being processed a second time, so it won't get stuck on cyclical links.

 - Should there be some sort of access control ability on the search node,
 limiting who is able to initiate a search?

 - Could the search node be used to get around property deny all access
 control in some cases, and return the forbidden data anyway?

The search is done with the identity of the requester, so while it may 
be possible that someone could attempt a denial of service attack by 
issuing multiple searches, it should not enable them to access data they 
wouldn't be able to access otherwise.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] bakefiles

2007-04-04 Thread Peter Amstutz
On Wed, Apr 04, 2007 at 07:38:11AM -0400, Reed Hedges wrote:

 Well, automake works fine for me in general on MinGW whenever I've used
 it there, but never tried it with Visual Studio or Cygwin. Of course
 there's always the incompatible-versions problem with the autotools.
 And maintaining a ton of visual C files sucks, I have to do that all the
 time :)

Well automake essentially works, the real bastard on mingw and cygwin is 
libtool.  Unfortunately you can't really use automake to build DLLs 
without libtool, at least not without a lot of hacking.  My main beef 
with automake itself is that it doesn't have good mechanisms for 
applying rules across the whole project (so we end up with the inplace 
boilerplate at the bottom of every file) and recursive makefiles suck 
for parallel builds.  It's not worth fighting with any more, and since 
we're going to be doing a lot of rewriting from scratch in s5, we might 
as well reboot the build system as well.

 That's good.  If we can keep those project/make files in the tree
 without too much trouble then that would be an ok way to go.  Let's also
 keep the bakefile source in the tree and in the source release too,
 especially if eventually we want vos to be buildable on all kinds of
 server operating systems (and where admins want to just run make and
 not have to install extra tools).

Before settling on bakefile I still need to get an idea of the strengths 
and weaknesses of the Crystal Space build system (Perforce Jam), 
Boost.Build (Boost Jam) and Scons.  Essentially bakefile is a 
meta-makefile more like automake but more abstract (and thus able to 
target a variety of underlying build tools), whereas Jam and Scons are 
full make replacements.  I still need to determine what specific unique 
features Jam and Scons offer that might tip the decision in their favor.  
Incidentally, it's probably possible to write a bakefile backend to 
produce Jam and Scons files ;-)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] s5 concurrency (design part 2)

2007-04-04 Thread Peter Amstutz
 in the vobject's queue and executed later.

All method calls with present only an asynchronous interface.  The call 
will return a future (also known as a promise in the E language) 
which is a handle representing the progress and outcome of the 
computation.  The caller can then do a number of things with it:
 - ask if the computation is completed
 - block until the computation completes
 - block until all results are known for a set of computations
 - get the result, if completed
 - get the error, if failed
 - get the progress of the computation
 - register a continuation to be executed when the computation completes
 - register a continuation to be executed when all results must be known 
for a set of computations
 - register a continuation to be executed every N seconds when progress 
has occurred

I anticipate that the preferred pattern will be to pipeline as many 
requests as possible, return to the caller, and later handle the results 
in continuations (essentially callbacks) as they come in.  This permits 
very lightweight, interleaved execution even with thousands of actors.

Something I'm contemplating would be the use of user-level threads 
(using make/swapcontext() on Unix, and either get/setThreadContext() or 
the fibers API on Windows) when calling the blocking calls above.  This 
would simplify user code a lot, as the user would not need to manage 
context and could avoid splitting an algorithm across function 
bounderies (which might otherwise be necessary to ensure that that 
control flow resumes in the proper place.)

The last thing I want to talk about here is transactions.  Because 
vobjects are relatively fine grained, there will be cases where it makes 
sense to do a read-modify-update action on several vobjects at once 
without anyone seeing the intermediate results.  To this without the 
possibility for deadlock will probably require a centralized lock 
manager, but otherwise seems straightforward: bind a set of vobjects to 
a particular actor, checkpoint their state (for rollbacks) and disallow 
outgoing messages to objects not part of the transaction that could 
change anyone else's state (like change notifications) until the 
transaction is completed.  With a proper model for expressing these 
state changes, we could develop more general change tracking into a 
version control capability.

I think that about sums it up my current thinking on concurrency.  
There's a couple of other things I'm mulling over (process migration 
being one) but for the most part I believe what I've outlined here 
consists of a pretty thorough runtime/concurrency model that hopefully 
hits the sweet spot of power, ease of use, ability to scale across 
multiple cores and processors, and ability to interface with 
non-threadsafe code.  Finally, the pure message passing/actor model 
greatly facilitates cross-language method calls (scripting!) which I 
will discuss in my next s5 design email.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Flux Worlds Server Announcement

2007-04-02 Thread Peter Amstutz
On Mon, Apr 02, 2007 at 09:26:59AM -0600, S Mattison wrote:

 The TerAngreal browser, I feel, doesn't serve as an integrative
 metaversal tool; because it uses proprietary OS-GUI-interface system
 calls, to generate the 'chat area' as well as the 'user list', and
 even the 'menus'.

Well ironically, the point of that is to serve integration with the 
user's desktop.  For various reasons, 3D-based GUIs tend to be clunky, 
due either to lack of polish (the GUI hasn't had the years of 
development attention that say GTK has), lack of integration with the 
desktop (things like cutting and pasting doesn't work like the rest of 
the desktop, if it works at all) or simply being slow (because the GUI 
is rendered on top of the 3D scene, the update rate of the controls is 
throttled to that of the update rate of the 3D scene as a whole.)

Thus, the use of WxWidgets to create a native look and feel was a 
deliberate design decision, not because it was easier (because it's not, 
it actually makes some things a lot harder.)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] bakefiles

2007-04-01 Thread Peter Amstutz
On Sun, Apr 01, 2007 at 09:28:41AM -0400, Reed Hedges wrote:
 
 Is it really bad enough to throw out our investment in the autotools
 configuration? bakefile is probably the most obscure of all the build

Whenever I try to set up a VOS build environment on Windows, I get a 
sharp, throbbing headache and a strong urge to throw my chair out the 
window.  It's difficult to understate just how big of a maintainance 
hassle the current build system is on Windows (whether Cygwin, Mingw or 
Visual Studio).  It's so bad that I've seriously considered creating a 
tarfile of the entire mingw tree on interreality.org as the recommend 
way of setting up a VOS build environment.  It takes me personally 
several days of fiddling to get ter'angreal to build and work on Windows 
on a new system.  Automake is lovely on Unix, but it is an awful 
cross-platform build system where the platform is not a unix variant.

Notice I didn't say anything about autoconf.  I would venture that we've 
probably invested more time in autoconf macros that automake hacks, and 
that autoconf is not the problem here, it's automake and libtool.

 tools you list.  If you do switch to bakefile, let's keep some Makefiles
 in the bzr tree.  And keep bakefile inside the bzr tree so that you don't
 have to have it installed if you want to modify the makefiles.

I know, bakefile is a little obscure, however it appears to have grown 
out of the needs of wxWidgets, which means it's already been proven to 
work for a large, complex multiplatform project.

The primary advantage of bakefile vs. jam or scons is that it generates 
actual project files for various compilers, so users don't have to drop 
down to the command line to build VOS when everything else they are 
doing is in the IDE.

 I'd suggest looking into scons, since it seems to be more popular than
 bakefile (it's also used by blender).  I have never used it though.
 Would jam be useful for generating VC projects or nmake files too?

While Crystal space does have the ability to generate visual studio 
files from its Jamfiles, it does so via a lot of extra jam rules and a 
perl templating system, so it's not easy.  That said, adopting the 
(jam-based) Crystal Space build system as a whole may be worth looking 
in to.

Finally, I guess I really should try out scons.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Spam on wiki

2007-03-31 Thread Peter Amstutz
I know, it sucks, I was deleting some of it last night.  I turned on the 
spam blacklist feature of MoinMoin (which had gotten turned off in the 
move from the old server to the new one) so maybe that will help.

I'm not sure if MoinMoin has a revert feature.  Need to dig into it 
more.

On Sat, Mar 31, 2007 at 02:08:30AM -0700, Ken Taylor wrote:
 A bunch of spam got added to the wiki between 3-25 and 3-27... I don't
 really know much about MoinMoin, but do you guys have a way of
 mass-reverting stuff like this?
 
 Ken
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] bakefiles

2007-03-31 Thread Peter Amstutz
I'm considering switching the VOS s5 build system from automake to 
Bakefile (http://bakefile.org).  The reason is that the maintainance 
overhead imposed by automake has started to get annoying, and that 
automake provides no support for building outside the conventional unix 
toolchain (for example, using Visual Studio).  The main recommendation 
for Bakefile is that it is used to by WxWidgets, which is a project with 
critical need for a cross-platform build system if ever there was one.

Bakefile is similar to automake in that rather than actually running the 
compiler itself, it is a sort of meta-makefile that is compiled to 
produce the actual makefile which does the actual work.  Unlike 
automake, bakefiles are designed to be retargeted to produce project 
files for a number of different build systems -- the big one for us 
being Visual Studio projects.  One thing that has impressed me about the 
bakefile system is that it has a target designed specifically to be 
integrated with autoconf (it produces Makefile.in files), so we can 
still do all the usual feature tests to configure the build to a 
specific platform.  Also, unlike a full build tool like Jam, due to 
bakefile producing files for the native build system, developers are 
able to build from source distribution without actually needing 
bakefile.

Does anyone have suggestions for other build tools I should consider?  
Other ones I can think of offhand are jam, bjam, ant and scons, all of 
which annoy me at some level (except for scons, which I haven't used.)

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] s5 design overview

2007-03-29 Thread Peter Amstutz
 guys are
 going to be focusing on the issue from the ground up.

My goal for s5 is to be able to support one million vobjects on a single 
site, on reasonable hardware.  We'll be doing benchmarks.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] How to host a product design dinner party

2007-03-21 Thread Peter Amstutz
Check this out:

http://earlystagevc.typepad.com/earlystagevc/

The most recent post about Web 2.0 talks about how he thinks the next 
big thing is going to be interoperability.  He mentions it more in the 
context of web services, but in fact many web services are a step 
backwards in terms of transparency, as a monolithic function-call API 
reveals little about the underlying structure of the data you are 
querying.

VOS as a platform for interoperability has a lot of potential.  What's 
unique, I think, is we're concerned with interoperability on multiple 
levels, thinking outside the web (HTTP/HTML) box, and application 
focused, so instead of fuzzy-headed theory or design by committee but 
we're actually trying to make it work for us in practice.

Walking into a presentation and saying A focus of the VOS platform will 
be on interoperability with existing systems makes people ears perk up, 
probably because the strategy for 99% of systems is platform lock-in.  
Since we're open source, we have no motivation to create lock-in, and 
ironically lack of lock-in becomes our own advantage.

Also, last night I came up with a new analogy for VOS:  
XML for Objects

Meaning, essentially, in the way that XML provides a meta-syntax for 
documents and enables a galaxy of tools and applications that can 
process them, VOS could provide a meta-framework for applications to 
interact, and similarly enable a galaxy of tools and applications that 
can interoperate with them.

On Tue, Mar 20, 2007 at 11:13:09AM -0400, Reed Hedges wrote:
 
 http://headrush.typepad.com/creating_passionate_users/2007/03/how_to_host_a_p.html
 

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] How to host a product design dinner party

2007-03-21 Thread Peter Amstutz
On Wed, Mar 21, 2007 at 04:07:10PM -0400, Reed Hedges wrote:

  Walking into a presentation and saying A focus of the VOS platform will 
  be on interoperability with existing systems makes people ears perk up, 
 
 Right, though that's a hard thing to promise.  Maybe we're willing to
 make VOS interoperable with other systems as required, and here are a
 few we've already done: x, y, z.  

 To add the it's-not-cookie-cutters part: you can organize your data in 
 whataver way fits with your need, and while this requires a bit more 
 work to actually do that, all the features and tools and other automatic 
 bits will still work.

It's true.  The advantages to VOS seem to be that it gives you a 
have-your-cake-and-eat-it-too approach to data structures; you can 
smoosh several data models together into the same logical object on the 
fly.  Among other things this means that you can avoid slicing whereby 
data specific to one data model is lost in translation because the 
target data model doesn't support it and doesn't have room for it.  In 
the VOS case, you translate what you can into standard object types, but 
can also attach your extended data and leave it there until you need it 
later when writing out the data to the original format.  Now, this isn't 
perfect (there could be data dependencies which arn't maintained if the 
standard data is changed without updating the extended data) but it's 
light years better than what most people are doing.
 
  Also, last night I came up with a new analogy for VOS:  
  XML for Objects
  
  Meaning, essentially, in the way that XML provides a meta-syntax for 
  documents and enables a galaxy of tools and applications that can 
  process them, VOS could provide a meta-framework for applications to 
  interact, and similarly enable a galaxy of tools and applications that 
  can interoperate with them.
 
 It's an OK analogy but only if you don't then start applying assumptions
 to VOS based on what XML is for and what it's restrictions are.

Right.  I'd only use this analogy with someone who already has a vague 
idea that VOS is about communicating objects and not documents.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] How to host a product design dinner party

2007-03-21 Thread Peter Amstutz
Well, I guess you proved Reed's point by misinterpreting the analogy...  
The point isn't really about XML per se, it's that the acceptance of XML 
has created an ecosystem of tools that operate on generic XML, which 
means applications using XML can leverage those tools.  We're proposing 
something similar in spirit, that a flexible runtime system can support 
the development of an ecosystem of applications that work together and 
are more powerful than the sum of their parts.

Otherwise I agree, documents are not code, and there's an ocean of 
difference between the essentially context-free, declarative nature of 
documents and the essentially stateful, imperative nature of code.

On Wed, Mar 21, 2007 at 04:35:18PM -0500, Len Bullard wrote:
 Not to rain on the parade but markup transliteration of objects has been
 done before.  See US Navy MID design prototypes.  If you use that analogy be
 sure to clarify that this is not a simple transliteration.  Using a syntax
 designed for documents to create a programming language turned out to be a
 not very good idea.  MID I eventually became the predecessor to XAML and XUL
 by about ten years.  
 
 len
 
 
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 On Behalf Of Peter Amstutz
  
  It's an OK analogy but only if you don't then start applying assumptions
  to VOS based on what XML is for and what it's restrictions are.
 
 Right.  I'd only use this analogy with someone who already has a vague 
 idea that VOS is about communicating objects and not documents.
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] http://research.sun.com/projects/darkstar/

2007-03-16 Thread Peter Amstutz
It's potentially interesting, although the details seem a bit thin at 
the moment -- there doesn't seem to be any obvious documentation on its 
architechture.  It's also non-free software (in the GNU/FSF sense) which 
is a drag.

On Thu, Mar 15, 2007 at 08:53:19PM -0700, HEBLACK, J wrote:
 http://research.sun.com/projects/darkstar/
 
 Should the page above be checked for the release or is that not
 something of use here?
 
 
 Project Darkstar is a research effort focused on the design of
 massive-scale, latency-optimized systems like online games. Written
 entirely in the Java programming language, the server platform provides
 a simple but powerful interface for defining server-side application
 logic. It takes care of persistence, load balancing, consistency and
 communications, leaving developers free to focus on their applications.
 
 
 -- 
 Entrante.fir
 Search name: excremento
 Find items: If any criteria are met
 Sender contains unclean
 Recipients contains unclean
 Subject contains unclean
 Message Body contains unclean 
 Source Account is HEBLACK, J [EMAIL PROTECTED]
 Then Move to Folder Inbox/Air alert
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] VOS making Moneys.

2007-03-16 Thread Peter Amstutz
I think what you're getting at is that we should take a broader view of 
what VOS could be -- and I agree.  The potential influence of VOS is 
similar in scope to that of the world wide web, and I'd like to make 
sure we get it right.

However, I'd also like to submit that interoperability is a key bridge 
that will enable people to cross over from the systems they are using 
now to our eventual VOS-based systems, so we need to consider the needs 
of existing platforms.  We also can't and shouldn't try to do 
everything, in particular so that we leave space for other people to be 
able to come in and experiment with their own ideas.

Conversely, it's also important to identify what existing systems are 
pretty good, and worth building on.  OS kernels (Linux) are pretty good.  
3D engines are pretty good.  Databases are okay (object databases seems 
to be a weak area).  GUIs are okay (we're in the midst of a slow 
paradigm shift away from raster graphics towards vector graphics).  
There are many many interesting programming languages on the fringe that 
are worth learning from.  Computer security is so awful it's definately 
worth looking at systems that ARE considered secure.

I don't know much about what investors want to hear, but a boil the 
ocean type of project to reinvent computing doesn't really seems like 
it brings enormous risk with it.  It's one thing if you are giving a 
grant to some fuzzy headed academics, but for VOS we're trying to 
straddle both computer science and practical software engineering.  
Hence the present focus on a relatively specific end product.

One thing I'm learning about presentation is that you need to have big 
ideas, but you also need a meticulous development plan to get there.  
The devil is in the details!

On Tue, Mar 13, 2007 at 05:54:51PM -0600, S Mattison wrote:

 Ah, true. But what sets this apart from the other interactive 3d world
 softwares out there? There are so many other communities, communities
 with names for themselves, why should I invest in VOS? This is what
 the investors will say. How does VOS stand apart from the crowd? What
 do I get in return? I'm not sure I fit in with a community of Linux
 Geeks. Well, unless you find a linux-oriented investor. I'm not
 saying it's impossible. I'm just saying that I have an idea that might
 make the idea a lot more appealing, and I know some people who can
 help set it up this way...
 
  That will get us to Step 2, which is to go for more significant investment
  funds and build a company that can capitalize on the platform more
  directly.  Then we sell VOS services far and wide, show up on the covers
  of magazines, and hopefully make it to Step 3 :-)
 
 So, you want to know my idea by now, and some of you may already have
 guessed... (Especially those who know me, or have payed attention to
 my previous rantings...)
 
 I propose we take VOS, and recode its back-end architecture to run
 just a little bit closer to the hardware, and add a software-rendering
 option. Give it power over various filesystem commands by using simple
 filesystem descriptor plugin-files. Give it the ability to access
 myriad protocols, to fill 3d objects with various online 1d and 2d
 content.
 
 Give it, also, if you're still with me, the ability to intercept,
 interpret, and render the window and terminal functions that are
 called by normal ELF binaries and drivers, as though these programs
 were actually running inside VOS itself (perhaps with their own
 descriptors so as to eventually support binaries from other OSs!). And
 for the final step, give it it's own hardware drivers, and create
 bootloader entries that call this program into it's own kernel mode!
 
 At that point, with these things: Specialized rendering, Filesystem
 access, Protocol access, and Parenting other processes, what need is
 there for any other Windowmanager? Since you can design your own
 interfaces within VOS, and create objects that, with a single click,
 hardlink/shortcut to open locations within protocols or filesystems,
 you don't need KDE, Gnome, or any other windowmanager. Since the
 descriptors are in place, there would be an open architecture to
 expand support for new filesystems, as well as child-binary emulation
 support, perhaps more advanced than WINE, since it aims at more than
 just Windows.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] http://research.sun.com/projects/darkstar/

2007-03-16 Thread Peter Amstutz
The Inquirer article mentions the GPL but I can't find any indication of 
licensing terms on Sun's own Project Darkstar page, except for the SDK 
download which appears to be a very restrictive non-commercial 
license.  They say open source right on the first page, but I can't 
find any indication that they actually mean it.

On Fri, Mar 16, 2007 at 09:27:49AM -0700, HEBLACK, J wrote:
 On Fri, 2007-03-16 at 09:57 -0400, Peter Amstutz wrote:
  It's potentially interesting, although the details seem a bit thin at 
  the moment -- there doesn't seem to be any obvious documentation on its 
  architechture.  It's also non-free software (in the GNU/FSF sense) which 
  is a drag.
 
 Well here is maybe a better vaporware article which talks of darkstar
 in terms of GNU and C++ and assembly wrappers:
 Sun talks about Darkstar cunning plan
 http://www.theinquirer.net/default.aspx?article=38137

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] XOD questions

2007-03-16 Thread Peter Amstutz
My basic complaint with X3D was that the transition to XML could have 
been an opportunity to clean up a lot of the syntactical warts of VRML 
(delimiting index face sets with -1, for example) while still keeping 
the basic data model.  We could have had a schema that follows the best 
practices for XML document design, follows XML data types, etc and would 
have been a breeze for developers to support.  Instead, they choose to 
do a translation that amounted to little more than replacing curly 
brackets with pointy ones.

Having written a minimalist X3D loader (just geometry) it irked me that 
I had parsing issues -- Parsing Issues, in XML! -- between files 
produced by two different programs because of the extra syntax embedded 
in CDATA that wasn't part of the DOM structure.

I'm not saying it doesn't work, it is primarily an aesthetic issue -- 
but it does cause headaches for developers.

On Thu, Mar 15, 2007 at 10:36:11PM -0500, Len Bullard wrote:
 Be fair, Peter.  It is the X3D instance you have to import, not the schema.
 
 The schema is baroque to put it mildly.  I'm not sure if it is used 
 for import.  BS Contact has a validating switch, but I've not tried 
 it.  The schema is useful for the x3d-edit utility, but even then, not 
 too many peole edit graphics like a document unless the are already 
 very familiar with the tree.
 
 len

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] http://research.sun.com/projects/darkstar/

2007-03-16 Thread Peter Amstutz
Ah, you're right.  So they are *going* to make it open source, but arn't 
quite there yet.  But it's good to hear.

It looks like Darkstar is mainly (exclusively?) a server-side 
technology, so it doesn't go quite as far up the application stack as 
VOS is targeting.  In other words, it doesn't address the browser 
question.  I am looking forward to their GPL release, though, since they 
are pushing the application high availablity/high reliablity and load 
balancing technologies and I'd like to learn about their architechture.

On Fri, Mar 16, 2007 at 10:48:16AM -0700, HEBLACK, J wrote:
 On Fri, 2007-03-16 at 13:31 -0400, Peter Amstutz wrote:
  The Inquirer article mentions the GPL but I can't find any indication of 
  licensing terms on Sun's own Project Darkstar page, except for the SDK 
  download which appears to be a very restrictive non-commercial 
  license.  They say open source right on the first page, but I can't 
  find any indication that they actually mean it.
 
 Here is the chief architects blog(Mar. 7) about that Sun Labs East
 picked it up:
 
 Darkstar goes Open Source and other updates-
 http://blogs.sun.com/gameguy/entry/darkstar_goes_open_source_and
 
 The Open Source model is ideal for the small developer. Build your
 product. Start making money. And then, when you have income, hire the
 authors of the technology you are based on to support that enterprise.
 Its a no front load scheme which is ideal for those with talent and
 creativity but not a lot of cash.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] XOD questions

2007-03-16 Thread Peter Amstutz
On Fri, Mar 16, 2007 at 07:39:44PM -0400, Reed Hedges wrote:

  So, it sounds to me like you want to append file A and file B to produce 
  file C, and that some of those pieces in file B are intended to modify 
  pieces of file A.  I see why you might want to do that.
 
 Sort of. Here's an example of what I was thinking of:
 
   load file=3dworld.cod/xod/whatever /
   vobject parent=/obj-from-file type=ex:extra
 ...
   /vobject
 
   extend ref=/obj-from-file type=ex:weird-type /

Oh, I see.  I think we've been arguing at cross purposes, because in 
fact the load tag in XOD already has a few commands special to it that 
do most of what you want:

  load file=3dworld.cod
!-- change site name of an object in the file --
rename from=objectA to=objectB / 

!-- add fileref as a child to current parent --
link name=foo fileref=objectC / 

!-- add a link to objectD going to mine
linkout fileref=objectD name=bar child=mine /

!-- add a link from mine to objectE --
linkin parent=mine name=baz fileref=objectE /
  /load

If we added an addtype command, which would be quite easy, then that 
should do what you want.

I should mention that in this case it makes sense to store it as a 
series of commands because they do in fact represent a set of edits that 
are made at run time to an existing external structure.  We're not 
declaring a new vobject structure from scratch in this case.

  Well, I feel like it should be more purely declarative and reflected by 
  the DOM structure, and not require that you have to in effect execute a 
  stream of commands 1, 2, 3, 4, 5, 6 in a specific order scattered around 
  the file to reconstruct the vobject structure.  
 
 This being what COD is, sort of, right?

Parts of it, yes.  The parts I'm less happy about.

 Anyway, eventually when we have OTDs we could use those OTDs to generate
 DTDs or Schemas and be able to say
 
 a3dl:sector name=world
   a3dl:object3d_sphere name=foo
 property name=a3dl:position0 0 0/property
 a3dl:material name=a3dl:material
   ...
 /a3dl:material
   /a3dl:object3D_sphere
 /a3dl:sector

Yes!  Exactly!  That would enable people to use VOS to create and use 
domain-specific languages very easily.

 Which would really be using XML to the fullest.  Except for when you
 want a Vobject to have two types, then we need some other way to do
 that, like
   multitype-vobject name=foo
a3dl:object3d_sphere
  ...object3d-related children...
/a3dl:object3d_sphere
misc:metadata
  ... metadata ...
/misc:metadata
   /multitype-vobject
 
 or some other way of using seperate XML elements for different types.

I hadn't really thought about it, but that seems like it would be a 
reasonable way to do it.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Typo in sector.cc

2007-03-16 Thread Peter Amstutz
Good idea.  This is what distributed version control is good for.  While 
you're at it, you can fix that synqueue.cc bug you pointed out, because 
I haven't gotten around to it ;-)

On Fri, Mar 16, 2007 at 08:38:58PM -0700, Ken Taylor wrote:
 In libs/vos/metaobjects/a3dl/sector.cc:
 
 void Sector::setCollisionDetection(bool enabled)
 {
 Property::setProperty(*this, a3dl:colision-detection, enabled);
 }
 
 bool Sector::getCollisionDetection()
 {
 bool b;
 Property::getProperty(*this, a3dl:colision-detection, b);
 return b;
 }
 
 collision is spelled wrong...
 
 Maybe I should make a bzr revision bundle so i can get my name in the log ;)
 
 -Ken
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Typo in sector.cc

2007-03-16 Thread Peter Amstutz
You can send it to me and Reed.  Or, alternately, you can publish your 
branch somewhere and I can merge it.

On Fri, Mar 16, 2007 at 08:59:58PM -0700, Ken Taylor wrote:
 Should I post patches to the discussion list or send them directly to you?
 
 -Ken
 
 
 Peter Amstutz wrote:
  Good idea.  This is what distributed version control is good for.  While
  you're at it, you can fix that synqueue.cc bug you pointed out, because
  I haven't gotten around to it ;-)
 
  On Fri, Mar 16, 2007 at 08:38:58PM -0700, Ken Taylor wrote:
   In libs/vos/metaobjects/a3dl/sector.cc:
  
   void Sector::setCollisionDetection(bool enabled)
   {
   Property::setProperty(*this, a3dl:colision-detection, enabled);
   }
  
   bool Sector::getCollisionDetection()
   {
   bool b;
   Property::getProperty(*this, a3dl:colision-detection, b);
   return b;
   }
  
   collision is spelled wrong...
  
   Maybe I should make a bzr revision bundle so i can get my name in the
 log
  ;)
  
   -Ken
  
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Message handler problem

2007-03-15 Thread Peter Amstutz
That's something that was introduced by the new event tables 
implementation in 0.24.  The solution is to make the registration 
function a templated class, and for the subclass to call the base class 
registration function with the subclass type to ensure that the method 
handlers are associated with the subclass as well as the base class.

On Thu, Mar 15, 2007 at 02:40:06PM -0400, Reed Hedges wrote:
 
 
 Ran into a slightly confusing thing that VOS does:
 
 If a base class registers a message handler, but then a subclass of that
 base class is the metaobject that's actually instantiated, then no
 messages can be delivered to that handler-- it seems that the list of
 handlers is keyed on typeid names, and VobjectBase is only able to find
 the handlers associated with the typeid of the subclass, not the base
 class.
 
 Any ideas on how we can fix this in VOS?
 
 Reed
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


  1   2   3   >