[vos-d] How databases hurt scalability

2008-10-04 Thread Reed Hedges

http://www.pbs.org/cringely/pulpit/2008/pulpit_20081003_005424.html

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


[vos-d] Sorry, need another test message

2008-08-23 Thread Reed Hedges

Just want to make sure the list still works after changing something...

Reed


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

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


Re: [vos-d] Rough graphs of #vos channel activity

2008-08-08 Thread Reed Hedges

Oops, just noticed that the days of the week are out of order.  Should 
fix that I guess. But there's an interesting upward trend toward the 
middle of the week, then it goes down to drop off on Saturday.

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


Re: [vos-d] babies

2008-07-31 Thread Reed Hedges

Interesting coincidence! Congratulations to you too!

Reed


Braden McDaniel wrote:
 On Wed, 2008-07-30 at 11:51 -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.
 
 Congratulations, Reed!
 
 My own competing project--Dylan Jesse--started a couple of weeks ago.
 
 Here's a picture from Day 2.
 
 Some more recent ones (and some previous ones) are here:
 
 
 http://www.kodakgallery.com/I.jsp?c=40tmq9nh.6uo36zg5x=0h=1y=bnzfdnlocaleid=en_US
 
 We're well into sleep deprivation at this point; but enjoying him
 immensely.
 
 
 
 
 
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


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

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


[vos-d] Web Site

2008-06-30 Thread Reed Hedges

Am thinking of switching over to the new website I was working on earlier
(http://interreality.org:4088), but without the half-assed
background image.  Would be nice to create a nicer one but don't have time.

I'll also do an editing and clarity pass to try to improve whatever wording I
can, and fix up the layout and Javascript issues.

I do think I'm just going to dump everything to a Wiki, either the current 
Moin, or
migrate to MediaWiki or something else.  It was great to eat our own dogfood by 
using VOS for the website, and it triggered some useful features and fixies, 
but that S4 dogfood is pretty stale by now!   If we get further along in S5 and
reimplement hypervos or something hypervos-like using it we can move the site 
back into that (and having available what the wiki gives us will be a good
features goal).

I'll include the current wiki pages but not really link them to the main site
except selectively, to avoid linking in too much confusing info... maybe have an
s4 category that collects all the potentially out of date info, and seperate
out ideas from current info.

Reed


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


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


Re: [vos-d] Web Site

2008-06-30 Thread Reed Hedges
On Mon, Jun 30, 2008 at 01:47:35PM -0400, Reed Hedges wrote:
 
 Am thinking of switching over to the new website I was working on earlier
 (http://interreality.org:4088), but without the half-assed

Go to http://interreality.org:4088/home to see it


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


Re: [vos-d] s5 properties proposal

2008-05-13 Thread Reed Hedges

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

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

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

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

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

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

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

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

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

...

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



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


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

2008-05-06 Thread Reed Hedges


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

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

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

Another interview, in video, includes some examples:

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

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


Re: [vos-d] s5 vobject properties

2008-04-25 Thread Reed Hedges

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

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

Reed


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


Re: [vos-d] s5 vobject properties

2008-04-24 Thread Reed Hedges

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



class Entity 
{
  handleMessage(); 
  setEntity* parents;
  string url;
}

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

class Vobject : Entity 
{
  listLink children;
  vectorEmbeddedProperty embeddedProperties;
  listComponent* components;
  etc.
}

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

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

class PropertyVobject : Component, PropertyCore
{
}


class Site {
  setEntity* entities;
}



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

I know this is simplified but does this make sense?

Reed



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


[vos-d] More on the web site

2008-04-03 Thread Reed Hedges

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

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

Any comments?

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


Reed


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


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


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

2008-03-03 Thread Reed Hedges



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


 I still think it would be easier for people to use VOS if the wrapper 
 classes had plain names, and the thing being wrapped had the funny 
 name.  E.g.

 DataType is the wrapper for DataTypeCore or DataTypeImp or DataTypeBase.
 
 The same reason I stated before, I want to avoid confusion between having a 
 reference to an 
 object and having an actual copy of the object.  We could call them Handles 
 instead of 
 Wrappers (so you would access objects through DataTypeHandle or 
 VobjectHandle) which might be 
 clearer.  Changing the name would be a hassle, though (search and replace 
 across dozens of 
 files).
 
 This is something of an artifact of how the C++ binding is implemented (due 
 to the limits of C++) 
 and can be done more cleanly in languages with better reflection facilities 
 or dynamic typing.
 
 I.e. it seems to me that at the most basic, and starting/newbie use 
 level users just need to work with wrappers. Through the vobject 
 wrappers they find children, access component wrappers, etc.  So this 
 use level should be the simplest and hide some of the complexity 
 that's going on.
 
 Well, the hope is that eventually newbies won't be using C++, they'll be 
 using Python or C# or 
 some other more civilized language.

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


Re: [vos-d] s5 hypervos (mod_vos)

2008-03-01 Thread Reed Hedges
Lalo Martins wrote:
 Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500):
 On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote:
 hypervos is already alive and kicking in the form of an Apache mod_vos;

Is the src/app/mod_vos directory in bzr current?



Reed


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


Re: [vos-d] s5 hypervos (mod_vos)

2008-03-01 Thread Reed Hedges
Reed Hedges wrote:
 Lalo Martins wrote:
 Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500):
 On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote:
 hypervos is already alive and kicking in the form of an Apache mod_vos;
 
 Is the src/app/mod_vos directory in bzr current?

I'd like to work on hypervos a bit in s5 and start bringing in some of 
the features I was working on in s4.   I don't want to deal with Apache 
at the moment though.  Can I split mod_vos.cc to seperate the Apache 
specific stuff out? (Or can you?)  If so, it would help to have some 
comments explaining some of the stuff it's doing (especially the Apache 
stuff, since I only know a little bit about Apache modules...)

Reed


___
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-01 Thread Reed Hedges
What is the Extension Manager? (WHat's an ExtensionManagerWrapper?)


What is a Service Manager (site.getServiceManager)?



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


[vos-d] Fwd: C++0x developments

2008-02-24 Thread Reed Hedges



 Original Message 
Subject:[liblf-dev] C++0x developments
Date:   Fri, 22 Feb 2008 12:47:36 -0500
From:   Bjorn Roche [EMAIL PROTECTED]
Reply-To:   [EMAIL PROTECTED]
To: [EMAIL PROTECTED]



Hey all,

I just wanted to update everyone on the latest developments in C++0x
(hopefully that will be C++08!). Lawrence Crowl, one of the members of
the committee gave a talk to google back in may about the developments:

http://video.google.com/videoplay?docid=3528799355371049884
http://video.google.com/videoplay?docid=3528799355371049884

One of the most important things is that C++ will have built-in
support for threads, including a memory model, synchronization and
atomics. Since he gave his talk, the committee has decided to add
limited support for fences as well.

Note that GCC currently has intrinsic support for atomic operations
(http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
) and even fences, so it's possible to build such types now that's at
least compatible with gcc. I'm going to write a prototype for and
atomic int for GCC if anyone is interested -- should be pretty simple
with those intrinsics, but who knows.

Lawrence sent me this. The papers are a bit hard to find, but knowing
which ones to look for helps a lot:

You can keep up at the C++ standards committee web site:

http://www.open-std.org/JTC1/SC22/WG21/
http://www.open-std.org/JTC1/SC22/WG21/

Under the link 'papers' you can find the latest papers in each area of
threading:

2007 N2427 C++ Atomic Types and Operations
2007 N2429 Concurrency memory model (final revision)
2007 N2440 Abandoning a Process
2007 N2459 Allow atomics use in signal handlers
2007 N2480 A Less Formal Explanation of the Proposed C++ Concurrency
Memory Model
2008 N2492 C++ Data-Dependency Ordering: Atomics and Memory Model
2008 N2493 C++ Data-Dependency Ordering: Function Annotation
2008 N2497 Multi-threading Library for Standard C++ (Revision 1)
2008 N2513 Dynamic Initialization and Destruction with Concurrency
2008 N2514 Implicit Conversion Operators for Atomics
2008 N2516 Threads API Review Committee Report
2008 N2519 Library thread-safety from a user's point of view, with
wording
2008 N2528 Timed_mutex in C++0x


___
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-19 Thread Reed Hedges
Reed Hedges wrote:
 Here are two ideas I had for a new website design.  Both are rough sketches.
 \

 2. http://interreality.org/~reed/tmp/iro/index2.html

I made a few small changes to this one, trying a different background 
image (the branches one is just to show the concept, it's a terrible 
render).

Put some little controls in the lower right to try different stuff out. 
  It does seem that having viewport-fixed objects, including background, 
really slow down firefox (when you scroll).

Reed


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

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


Re: [vos-d] Updated Road Map on Wiki

2008-02-19 Thread Reed Hedges
reed wrote:
 
 I updated the Road Map page on the Wiki to reflect S5 plans.  Pete, please 
 correct it if it's a bit off.  This is just a general guideline, we don't 
 really know yet when the first S5 release will be, or whether it will be a 
 1.0 release or a beta or testing prerelease that is less easy to use.
 
 http://interreality.org/wiki/VosRoadMap

I decided that in addition to a Blender export script, import from 
Google Sketchup (or export from it to COD or XOD) would be really good. 
  It's very easy to learn, and some people interested in VOS might 
already know how to use it (it's the main app for creating objects to 
drop into Google Earth).  Is this a good idea?  I added it to the road 
map.  This would be an easy contribution from anyone in the community 
who already knows ruby.

I'll also make the changes you mentioned Lalo.

Reed




___
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-19 Thread Reed Hedges
Lalo Martins wrote:
 I like #1.  When I did a mockup a long long time ago, I went with a 
 similar idea, and I think it's still valid; the metaphor being that 
 you're looking at a few flat widgets floating in a 3d space.

The main thing I don't like is it's too dark and black, which might 
scare some people off a bit :)  (Even if just subconciously).  Maybe 
I'll make a different render that has more of a twilight or sunrise 
gradient to it, and I want to find better background images for the boxes.


 
 Also, in my own mockup, I used partial opacity in the boxes.  Maybe mine 
 were too transparent, but something like 90%, 95% would look good?  (The 
 problem with a lower value being, of course, that the Celestia background 
 was black with white stars, which would clash with the text...)

I tried some transparency, but it does slow down rendering, and with 
such sparse stars it doesn't add much. If there were more or better 
stars or more planets or other scenery in the BG that might be cool. 
Maybe a PNG with alpha transparency wouldn't slow it down as much, and 
it could provide better borders.

I did want the background to look very CGI, could even turn it into flat 
unsmothed polygons or put a wireframe on it.


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

___
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 Reed Hedges

I made the divs a bit transparent in #1.  I think they're too boring though,
maybe need a bit more bubbliness? (Or is that too Web 2.0? :) Or more of a
border?

I just threw together the background images in blender, but I do like having
them look more polygonated and emphasising that they are 3d graphics.

With the second design, my idea is also that there would be a set of similar
background images, but with a different one for each page. (or randomly selected
when loaded). 

The background in #1 and the menu in #2 are fixed to the viewport, but I haven't
decided if that's a good idea yet.

And I'm just having fun experimneting with the javascript mouseover effects.
Let me know if you think they would work.

Reed


On Mon, Feb 18, 2008 at 05:24:32AM +, Lalo Martins wrote:
 I like #1.  When I did a mockup a long long time ago, I went with a 
 similar idea, and I think it's still valid; the metaphor being that 
 you're looking at a few flat widgets floating in a 3d space.
 
 I have a nice background image I generated from Celestia :-)
 
 Also, in my own mockup, I used partial opacity in the boxes.  Maybe mine 
 were too transparent, but something like 90%, 95% would look good?  (The 
 problem with a lower value being, of course, that the Celestia background 
 was black with white stars, which would clash with the text...)
 
 best,
Lalo Martins
 -- 
   So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
   http://lalomartins.info/
 GNU: never give up freedom  http://www.gnu.org/
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

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


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


[vos-d] Future of the Blender UI

2008-02-18 Thread Reed Hedges

Here's Ton talking about some changes to the Blender UI code:
http://www.blendernation.com/2008/02/18/the-future-of-blender/

Our UI client ideas are somewhat similar to the kind of things Blender does.  If
they make the code reusable and general enough, it's possible that we could even
use it to make our UI client.   Ton seems to want to get the changes done pretty
soon. 

The internal code changes are to use a more general event system for UI and tool
actions, and make all the UI infrastructure accessible and customizable from
Python.

Reed


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


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


Re: [vos-d] Future of the Blender UI

2008-02-18 Thread Reed Hedges

 The internal code changes are to use a more general event system for UI and 
 tool
 actions, and make all the UI infrastructure accessible and customizable from
 Python.
 


Here's more

http://wiki.blender.org/index.php/BlenderDev/SundayMeetingAgenda/December_23rd_2007
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Status


Reed

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


Re: [vos-d] Updated Road Map on Wiki

2008-02-15 Thread reed
Posted at: http://interreality.org/phorum/read.php?2,180,185#msg-185
reed wrote:

lalo Wrote:
 It's not up to me, but I'd do a more testing r1
 (r0?) earlier, maybe as 

A second preview release, similar to the one Pete made a little while ago 
with the user interface client, you mean?  Sure, might be good.  Let's add it 
and if we are able to do that, we can, and if we don't feel like it's worth it, 
skip it.


 On the other hand, some things that are in your r2
 will be there in r1 in 
 summer, or even r0 in spring, because I'm
 working on them 
...
 hypervos is already alive and kicking in the form
 of an Apache mod_vos;
...
 And the first scripting language
 will be there a week 
 after Peter adds marshaling (which language that
 will be depends greatly 
 on my mood that week, though).
 
...
 maybe I'd sort them differently :-)



Go ahead and update the wiki page (http://interreality.org/wiki/VosRoadmap).

Reed

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


[vos-d] Updated Road Map on Wiki

2008-02-14 Thread reed
Posted at: http://interreality.org/phorum/read.php?2,180,180#msg-180
reed wrote:


I updated the Road Map page on the Wiki to reflect S5 plans.  Pete, please 
correct it if it's a bit off.  This is just a general guideline, we don't 
really know yet when the first S5 release will be, or whether it will be a 
1.0 release or a beta or testing prerelease that is less easy to use.

http://interreality.org/wiki/VosRoadMap

Reed



___
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-02-14 Thread Reed Hedges

Croquet is very cool. I know Pete and I have been following it and reading about
it since we started VOS.  I don't know if its details have influenced our design
much, but some the end goals and features are similar.

A lot about it is not documented, as far as I can tell.  It's all is Squeak, 
which can be an obstacle (both because of the language and because of the way 
some things must be done within the framework.)  And it doesn't really come 
with much out of the box (though at this point, neither does Interreality).
With networking, it was designed to support a few particular features, which are
sort of unusual (originally meant for a LAN only, no internet; in a sense it's
really a number of seperate single-user worlds, that can optionally 
synchronize). 
We've taken a more practical and direct approach I think.

There is a commercial product based on it that appears to be fairly complete and
work well (quaq.com).

Reed


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


Re: [vos-d] Updated Road Map on Wiki

2008-02-14 Thread Reed Hedges
On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote:
 hypervos is already alive and kicking in the form of an Apache mod_vos; 


Ack! Why didn't you email the list! I've been adding stuff to S4 hypervos (and 
intend to port them to
S5!) And I have many plans for further development (see HyperVosIdeas on the
wiki)

Tell me more about mod_vos.

Reed


___
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-10 Thread Reed Hedges
Lalo Martins wrote:
 AIUI from IRC conversations, the site IDs won't actually be visible to 
 the application programmer later on; we'll deal only with IDs like /vos/
 core/StringProperty.  (I'm not sure about the code namespaces, but I 
 hope some simplification is intended there too ;-) )  Peter has actually 
 told me a few days ago that side IDs being required for the type 
 attribute in XOD is a bug.  For now, we cope; the IDs are extra work, 
 but not really a killer.

Aha, that's nicer then, and sounds similar to how I was hoping it would 
work (with the name (e.g. StringProperty) as the actual name used by 
humans).  I will miss the foo:bar type syntax, but that's OK I guess if 
in the new syntax things are equally expressive but terse.

Curious what the bug is; what's missing from s5 that will fix this? 
(Curious so I can understand S5 a bit more.)


 All C++ files except for main.cc (and in my branch, plugin.cc) are 
 generated.  Here's how I observed it works:

Thanks!   Does one just run voscodegen with the xod file as input to 
generate the code?

Reed



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


[vos-d] s5 build errors

2008-02-09 Thread Reed Hedges


Can this be fixed, or is there a way to disable sitetest, or have scons 
skip it or something?

g++ -o debug/build/src/test/sitetest.o -c -g -Wall 
-Idebug/thirdparty/stage/include -Idebug/stage/include src/test/sitetest.cc
src/test/sitetest.cc: In function 'void sitetest_verify_signature()':
src/test/sitetest.cc:8: error: 'vos' has not been declared
src/test/sitetest.cc:8: error: expected `;' before 's'


___
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-09 Thread Reed Hedges

The new type IDs are still bothering me a bit too (among other things, 
like the code namespaces).  A huge advantage of the old user-invented 
type names is that they were natural to understand and easy to remember. 
   We're going to have to do a lot of cutting and pasting, and when we 
get one digit wrong, will be tearing our hair out over it.  (Or the only 
option will be to use the GUI tool.)

Why not have a type/class have separate secure (crypto) ID, and name. 
  When you use a human-readable name in the UI client or in a XOD or 
whatever, VOS could just look up the OTD/record of the type/class and 
gets its crypto ID, and throw an error or ignore it if there are name 
conflicts or not found.  In the actual internal inter-object 
references/links it would use the crypto ID.


Also, what in the HelloWorld example is autogenerated and what isn't?

Reed




Lalo Martins wrote:
 Is there any rhyme or reason to site ids?
 
 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?
 
 Or is this (library OTD) going to be substantially different later on?
 
 best,
Lalo Martins


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

___
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 Reed Hedges

Started listing S5 changes at:

   http://interreality.org/wiki/S5
   http://interreality.org/wiki/ChangesToA3dl

Will fill them in a bit as I go through the vos-d archives and talk to 
Pete more.

Reed


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


[vos-d] More new S5 classes/concepts

2008-01-22 Thread Reed Hedges

I'm going through S5 a bit more deeply now.

Pete, can you give a summary explanation of these new classes/concepts, 
and how you use them, what they do, etc.

What are:
   ComponentWrapper
   Promise
   Status (used with a Promise it seems?)
   IVobject
   VobjectImpl
   ImplementationWrapper
   ImplementationComponent
   ConstructorFunctionWrapper
   ConstructonFunctionFunctor
   ConstructorFunctionComponent
   The host's factory (i.e. from Host::getFactory())
   ParentChildLinkWrapper
   the SITE_...blahblah..._NAMESPACE namespace
   DataType
   DataTypeWrapper
   Class
   ClassWrapper
   the vos:abcdefg12345...[1]/foo/bar strings that appear various places
   What is something's owner (i.e. the getOwner() virtual methods that 
lots of classes have)

What kinds of things are generated by the code generator, and from what 
bits of information?

Can you explain 'MVC' a bit more (it seems to now be part of the library?)

In interreality3D, how does it use MVC? What is, for example, an object 
like wxMultiframeContextWrapper and wxMultiframeContextComponent?  What 
is the wxgui namespace.

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 
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?

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


I'll start a NewStuffInS5 wiki page or something, including some of the 
previous discussion on vos-d.


Reed


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


___
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-22 Thread Reed Hedges

And just a general impression... S5 is becoming really complex and 
daunting (and sophisticated, and hopefully very powerful) piece of 
software.  But this means that we're going to need to put a *lot* of 
work in documenting, tutorials, as well as just polishing and refining 
the API itself, to make it easier for newbies to understand, or at least 
get started with the most common operations (like creating new 
types/components, etc.)  Just something to keep in mind as it's being 
developed and designed... if you think of a way to make it make more 
sense or be more natural, at least post it somewhere for future 
consideration

Reed



___
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 - OTD XML

2007-12-07 Thread Reed Hedges
On Fri, Dec 07, 2007 at 06:01:30PM +, Lalo Martins wrote:
 Also spracht Reed Hedges (Fri, 07 Dec 2007 10:57:10 -0500):
  Oh, ok, then my sketch is not really SOD, just a similar thing. Sorry
  for apropriating the name.  I didn't know that you implemented your
  format (or forgot).  Why wasn't it merged into the main S4 repository?
 
 Hmm... ehn... that's a good question :-P didn't even think about it.  
 Guess s5 came around before I could finish it?
 
  I couldn't access your bzr repository, can you maybe post an example SOD
  file just so those of us getting nervous about editing all that XML can
  relax a bit :)
 
 Ah yes, the repository was in a temporary location... I now pushed it to 
 http://interreality.org/~lalo/bzr/sod (or for those who can, bzr+ssh://
 interreality.org/home/lalo/bzr/sod).  I also checked it out there, so you 
 can actually see the source by going to the same URL; the example is at 
 http://interreality.org/~lalo/bzr/sod/doc/examples/3dworld-blocks.sod


Looks nice. My only comments are that the ...end syntax is a bit unexpected
(would have used braces, and/or allow a block to be on one line with some
seperator other than newline, like ;), and was initially confused as to what 
with: meant.  Also, to give a property a value and a type you must use 
with:...end, right, you can't have a one-line property with a type?

But anyway, it's nice and minimal and would be a good addition to VOS, I'll add
it to xplanner or something.


Reed


___
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 Reed Hedges

I don't know about Karsten, but the reason I have a knee-jerk reaction 
against suffixes like Wrapper is that it just feels like cruft, based 
on other systems where the word had no consistent meaning, at least from 
a user's perspective, it just seemed a hack to extend an API or 
facilitate its use without changing the deeper classes, or it was in 
fact an implementation detail that just happened to be exposed to the 
user.

It's another naming issue I guess.  Call it a Handle and use an H 
suffix. Or an Accessor.   Call it a Lever, I don't know :) Wrapper 
just has bad connotations to some of us :)  (Maybe like Component)  In 
the end it will just be something that a C++ user has to learn what it 
means, but at first glance they have to have trust that it's actually 
very useful and that there's a good reason they have to do that extra 
typing.

Reed


Peter Amstutz wrote:
 On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote:
 
 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.
 


___
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 - sites, hosts, and URLs oh my

2007-12-06 Thread Reed Hedges
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 are two layers, host and site, where before there was just a site.

Peter, does the following sound more or less like the way it's going to 
work or could work, roughly speaking? --   First, you contact a host, 
then you find the site and its vobjects.  You either already have a 
connection, or you have a URL like 
vip://interreality.org:4231/MyCoolWorld/thing.   You could say that 
interreality.org:4231 is the name of the host.   Then you go looking 
for the /MyCoolWorld/thing vobject, which is part of some site hosted on 
this host.  You could just send the host the name of your vobject 
(/MyCoolWorld/thing), and the remote host looks up which of its sites 
(if it has more than one) that vobject is part of [vobjects on different 
sites would have to be children of different root vobjects, like 
/site1, /site2, /MyCoolWorld], and returns a message informing you of 
your requested vobject's site identity information, you do key 
authentication, etc.  The site doesn't really have a name, but it has 
its key, and on any given host it has a unique root vobject that all its 
other vobjects are underneath (though that root could have different 
names on different hosts).This is not too dissimilar from the site 
handshaking/negotiation in S4, I think, it just has the extra part where 
you need to tell the remote site what vobject you want so it can figure 
out which site to use for that vobject, and tell you.

Yes, nobody should really have to every care about the actual site 
ID/key strings, unless they're debugging something or it happens to be 
useful in some code to have a unique value that  identifies the site 
(i.e. in S4 you would have used the site's URL for that) or are 
developing something more advanced involving site replication or 
distribution or whatever.  Or they are suspicious about a site's 
identity and want to manually verify whether it matches some record . 
End users (surfers) would still have URLs.

Though one thing I do want to get into the client application etc. more 
quickly than we would have in S4, is reimplementing the service 
directory we had in S3.  It incorporated both online directories of 
services (e.g. a 3D world), and LAN discovery.

Reed



___
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 Reed Hedges

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.

Reed



___
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-12-03 Thread reed
Posted at: http://interreality.org/phorum/read.php?2,118,129#msg-129
reed wrote:

KAO Wrote:
 runtime. All in all, I think they deserve their
 own name, and  
 Component just isn't it.

Maybe we could go the way of VObjects and call them VComponents, though that is 
a bit cumbersome-- they're all under the VOS namespace anyway.  Module might 
work but that's often used for higher level application parts too.  (And as a 
synonym for plugin).

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


[vos-d] Wiki now requires a login to post

2007-12-03 Thread reed
Posted at: http://interreality.org/phorum/read.php?2,130,130#msg-130
reed wrote:

I changed the default ACL of the wiki (http://interreality.org/wiki) so that 
only known users can edit pages.  So you must log in first.  Another 
anti-spam measure.   

There's also a new group called EditorsGroup, members of which can delete 
pages and revert changes.  I put Peter, myself and Ken in that group, since we 
are the most active on the wiki in recent past.  If anyone else is using the 
wiki actively and wants to be able to delete and revert pages (usually to undo 
spam changes) just let me know and I can add you.

Reed



___
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 Reed Hedges

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


Re: [vos-d] notes from IRC, pt 2

2007-10-24 Thread reed
Posted at: http://interreality.org/phorum/read.php?2,110,115#msg-115
reed wrote:

Peter Amstutz Wrote:
- 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).

Minor mode should be indicated in the status bar (so should major mode 
actually).

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

The panel header bars and what controls on it will have to be refined over 
time. There are several little tricks we could use to make them more elegant, 
but should probably wait to see what the most important operations will be.

Splitting could be frequently used, but only in some use situations. I.e. it 
depends on what kind of thing you're doing in VOS.

How about putting those buttons in a toggle control, but sync all the toggle 
controls. I.e. a little button in each pane title bar causes a set of splitter 
buttons to appear or disappear in all title bars.

Or hide that set of buttons except when you mouse over that area.

Or make it a menu option.

A key binding could also be used to show/hide those buttons (like hold down 
shift).

I think we could also make the panel headers have two states, big and small. In 
big state it could have all the stuff it currently has, but on two lines and be 
less crowded.  In small state.

Some additional panel controls I think might be useful:
 * Buttons to do a combination of split and set major mode
 * Minimize/Restore the pane to a very small unobtrusive button
 * Minimize/Restore all other panes except this one.
 * Collapse/Restore the pane to just its header (like MS Word's panels IIRC)
 
 
  - Mentioned running out of space in the window
 when using the mouse to 
 move.

I have this same problem. Should keep walking or turning when the mouse is at 
the edge of the screen.   Or act like S4 and use click to walk, mouse to turn 
only.


  - 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.

I think we should reserve multi-key chords for more advanced actions.  I don't 
see why we can't use any CTRL key we want, including CTRL-SHIFT keys, and also 
the F-keys.  Let the OS have ALT.  



 
  - Agreed the the UI will probably become clearer
 once its purpose is 
 clearer.  Lacking the ability to do any
 interesting browsing or editing 

Any ideas on how we can set up something in the prototype that shows this? 
Maybe set up a special view of interesting objects that you can play with, 
like change colors of the trees or something?


Reed

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


[vos-d] S5 and ordering listeners

2007-10-22 Thread Reed Hedges

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?

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


___
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 Reed Hedges

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.

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. 
  One possability is to use a wiki for all the pages, and then 
transition back to hypervos once S5 is ready for it.   We could have 
some pages consist of more free form brainstorming and draft 
documentation like the current wiki, and some pages be the more public 
facing webpages, but those pages could be smaller but interlinked.  More 
detail below.

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

I'm also planning on figuring out how to set up a somewhat customized 
drupal site for a different project, so if that works out maybe we could 
use that.

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


About Section
-

This is where we explain what the heck Interreality is, and sell it. 
One thing we could do is have a set of short descriptions, each aimed at 
a different kind of person who might be interested, or describe in 
general terms how you might approach solving particular problem or 
implementing a type of idea using VOS.

Docs


Here we have short articles that explain how to do specific programming 
tasks with VOS (howto's), as well as the reference manuals.  We should 
probably take S5 as an opportunity to split up the reference manuals, to 
have one for each library.

I don't know if we should just update the Creating Interreality 
manual, or split it up into smaller documents.  I'm inclined to split it 
up a bit, or at least separate the VOS Design document from the more 
practical program/how-to manuals.



___
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 Reed Hedges
On Fri, Oct 19, 2007 at 05:16:27PM -0400, Peter Amstutz wrote:
 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.

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?

Other things that can go into saved GUI configurations are shortcut commands for
the particular application. Esp shortcuts to creating objects of a certain type.
So if you are in 3D mode and are going to create a new object, the menu gives
you all the a3dl types (at the top of the list.)

It should also remember your last UI configuration and could also ship with a
default configuration in a file. Having the UI configurations in files lets
people set up configs for different purposes or users and share and redistribute
them.

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

This could be part of the default UI configuration. (I actually am not a fan of
having login be a full panel, it should be a temporary panel or dialog box
shown by other view modes as needed.)

 - Discussed that the goal is for UI controls to be per-world 
 configurable

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. 

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?

Reed

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


Re: [vos-d] Forums integrated with mailing lists

2007-10-19 Thread Reed Hedges

Here's an RSS feed for the vos-announce form/mailing list:

http://interreality.org/announce.rss

(actually, it's an alias for the RSS feed that the forum software generates, but
this abstracts that in case we change forum software or whatever. vos-d also has
an rss feed, just go to its forum page to get it.)

Reed


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


Re: [vos-d] Forums integrated with mailing lists

2007-10-19 Thread Reed Hedges

I think it would be ok to just black it out (e.g. [EMAIL PROTECTED]). It's 
not that useful to have email
addresses visible, this is just an artifact of how some email clients do 
replies.


On Fri, Oct 19, 2007 at 11:07:22AM -0400, Peter Amstutz wrote:
 Posted at: http://interreality.org/phorum/read.php?2,88,96#msg-96
 Peter Amstutz wrote:
 
 After a quick scan of the phorum modules listed on their site, I didn't find 
 anything that specifically obscures email addresses. It probably wouldn't be 
 too hard to do, and I have already had to do a bunch of modifications to the 
 email modules used to tie the forum to the mailing list (and I've never 
 written php before!)
 
 I do wonder how effective email obscuring is, these days. It's not hard to 
 write a bot that would use a regular expression like (.*) at (.*) dot (.*) 
 in addition to the usual (.*)@(.*) ...
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

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


___
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 Reed Hedges

Just thought of this: One thing that a remote app. might want to customize about
the UI is how some things are labeled, or it might want to add special
informational labels/text blocks/tooltips/bubbles/whatever.

Reed



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


Re: [vos-d] Forums integrated with mailing lists

2007-10-19 Thread Reed Hedges

Nope. You can see here: http://interreality.org/phorum/read.php?2,88

Reed

On Fri, Oct 19, 2007 at 02:43:08PM +0200, [EMAIL PROTECTED] wrote:
 Hi Peter,
 
 I hope the mail addresses are not open readable in forum then, or we might 
 get a lot of spam here soon?
 

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


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


Re: [vos-d] s5 version control and persistence

2007-10-17 Thread Reed Hedges

On Wed, Oct 17, 2007 at 02:53:49AM +, Lalo Martins wrote:
 Also spracht Reed Hedges (Tue, 16 Oct 2007 10:24:27 -0400):
  - type list
  - child list
  - payload, if any (eg properties)
  - security capabilities
  
  - parent list?
 
 That would be problematic.  Since the PCRs are already represented on the 
 parent side, having them repeated on the child would open a potential 
 spot for corruption.  Also, it kind of breaks the idea that an object 
 only commits itself; if it adds a new child, then the child would have 
 to update its parent list.  Most of all, I don't think it's necessary.


Yes, it's redundant and could be problematic.  But what if you have some objects
in storage, and you want to revive them, and have them insert themselves as
children of another object?  They need to remember what their parents were.
I.e. any situation in which some version gets disconnected from its parents
needs to remember what its parents were.  

This could just be a special case, where you keep track of them but 
normally you don't need to use them about them, except in situations 
where you're recovering from a network problem or change which broke 
the link, or moving objects out of persistant storage,etc.

  Version control: how it's stored
  
  Hmm, it seems the only thing that you need to reason about merging is
  textual property data.
 
 I don't think so.  I think the most common type of merging we'll have 
 is on child lists.

True, their ordering could conflict.  Maybe in that case you just do the best
you can, that's pretty easy for a user to fix in applications where order
matters. (Or e.g. some code triggered by a listener has to resort them or 
whatever.)  
In text, if things get too messed up, it can be a real pain to fix
manually, since information tends to span multiple lines.

 
  I think we should really never have any
  situation in which there's a conflict, unless you as a user
  specifically command it to merge two divergent branches, then of course
  you are there to resolve conflicts.
 
 Right.  In all other cases, I suppose the newer revision overrides the 
 older one, when there is conflict.
 
  What would the downsides be to treating payload (e.g. property data) as
  atomic?   We can do diffs in a version history UI to present it in a
  nicer way.
 
 We could.
 


  Horizons
  
  
  Off the top of my head, I think we'd like to be able to set a horizon
  per host, per type, and per vobject, in that order of precedence
  (vobject overrides type).  What if a vobject has two different types
  that specify a horizon?  Respect the first?  The last?
  
  What is a horizon??
 
 A preference of how many historical revisions to keep.  You may set your 
 host globally to a horizon of, say, 10, to save space; or set some less 
 important object to a small number, because you don't care...

Part of this might be archiving old revisions to disk, either in a known place
where they can be called up again, or archive and forget.


Reed


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


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


Re: [vos-d] s5 version control and persistence

2007-10-16 Thread Reed Hedges

This sounds really good. Having replication and clustering will be 
really important as we move forward.  It will let us do all kinds of 
scaling and load distribution, and even manage things like internal, 
in-development or draft datasets that get published to a public site 
when ready... lots of great possabilities.



 
 What we're thinking is to take this one level further, and implement
 persistence itself as a host; so even in a single-host setup,
 persistence would be a discrete thing,

This makes a lot of sense.

Replication also indicates one path to bridging different networks or 
different network transport mechanisms.  I.e. you can have two sitehosts 
that mirror each other, one which is accessible over VIP, and one which 
is accessible over some obscure shared memory or other communications 
system.



 A version control branch corresponds to a concrete site, by which I mean
 the information about one site as seen by one host (as opposed to the
 full site, which is the most up-to-date version as seen by the whole

We should probably come up with some specific names for these things.

Like:

Site = A collection of vobjects that live together in one conceptual 
set, and may all be accessed in the same way (e.g. over VIP talking to 
one internet host).

Host or Server = A server program (E.g. omnivos) that holds some 
vobjects in a site (maybe the whole site) or one replication/mirror 
within a site that has several replications. Or repository?

Site version? = A copy of a particular version from a site's vobjects' 
revision histories. This could be said to be a version 'derived' from 
the 'ancestor' site.  [should avoid calling them parents/children, to 
avoid confusion with vobject structure.]   Or is this what you mean by 
branch?

... etc.


 
 - type list
 - child list
 - payload, if any (eg properties)
 - security capabilities

- parent list?


 
 Version control: how it's stored

Hmm, it seems the only thing that you need to reason about merging is 
textual property data.  I think we should really never have any 
situation in which there's a conflict, unless you as a user 
specifically command it to merge two divergent branches, then of course 
you are there to resolve conflicts.

What would the downsides be to treating payload (e.g. property data) as 
atomic?   We can do diffs in a version history UI to present it in a 
nicer way.


 Revisions and transactions

Sounds pretty good, not sure I understand all the issues with local 
objects doing commits.  Any particular call chain would be building up a 
list of commits, that would be executed by the initial vobject that got 
the message before it returns from handling the message and sends any reply?

Regarding transactions, is this something that could be saved for later, 
after the basic revision control is implemented,or does it have to be 
integrated now?


 
 Horizons
 
 
 Off the top of my head, I think we'd like to be able to set a horizon per
 host, per type, and per vobject, in that order of precedence (vobject
 overrides type).  What if a vobject has two different types that specify a
 horizon?  Respect the first?  The last?

What is a horizon??


Reed


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


[vos-d] Douglas Englebart and some Google folks talk about knowlege tools and organizational improvement

2007-09-05 Thread Reed Hedges

Brief oververview of Englebarts vision and ideas, talking to folks at Google.


http://youtube.com/w/?v=xQx-tuW9A4Q



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


Re: [vos-d] issue building on OS X

2007-08-30 Thread Reed Hedges

Pete has a Mac so maybe he can help.

I guess you have neither readline nor termios, so it's trying to use 
getch() from curses. Can you post the 'config.log' file that should have 
been created in the main build directory?

Can you grep for the getch() function somewhere, it should be in 
curses.h in the standard includes directory (is it /usr/include on OSX 
or something else?)

Reed



Jake Franklin wrote:
 Thanks Reed, I'm running automake 1.6.3
 
 The build got much further this time, but seemed to die when building mesh:
 

 g++ -DHAVE_CONFIG_H -I. -I. -I../../libs/vos -I../../libs
 -I../../inplace/include -I../../inplace/include/crystalspace
 -DINSTALL_PREFIX=\/usr/local\ -DVOS_EXPORTS  -D_REENTRANT
 -D_PTHREADS -I/Users/jake/vos/vos/inplace/include -D_REENTRANT  -O1
 -D_REENTRANT -D_PTHREADS -fvisibility=hidden -g -Wall
 -I/Users/jake/vos/vos/inplace/include -c -o util.o `test -f 'util.cc'
 || echo './'`util.cc
 util.cc: In function 'std::string mesh_read_input(const char*)':
 util.cc:634: error: 'getch' was not declared in this scope
 make[3]: *** [util.o] Error 1
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all-recursive] Error 1
 

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


Re: [vos-d] development plan

2007-07-22 Thread Reed Hedges

 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.

Hmm... I kind of want to begin porting S4 libraries and apps (mesh, 
omnivos, hypervos, the metaobject libraries, etc.) over to S5. Should I 
just wait on that?  Networking is probably needed (though maybe not). 
Metaobject/type API is needed. Message handling would be needed.

Reed

___
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-07-08 Thread Reed Hedges

I thought of another thing: fix up the blender export script.  At this 
point it's a crucial key to making 3D worlds that you can use in 
Interreality, and probably will be in the future as well.  (Though, 
anyone tried out the ASE converter recently?)

Some things it needs to be update for are:
  * Get meshes' properties (part of the game engine logic stuff) and 
make them into vos properties
  * Maybe output vobjects for Empty Blender objects (and follow their 
parent-child relations)
  * Needs an actual UI where you can select options, rather than just 
the menu subitems

Anyone tried this script recently? Have any problems that need to be 
fixed or missing features added?

In a little while I'll consolidate possible tasks for 0.24 and we can 
prioritize them (we probably won't be able to do all of them, we ought 
to release 0.24 pretty soon).

Reed



Reed Hedges wrote:
 Are there any bugs or real defects in Ter'Angreal or VOS?  I know of two, 
 don't
 know if we should fix them:
 
  * Avatar settings (model/skin) aren't saved (really just an unimplemented
feature)
  * Objects aren't always removed from the world
 
 Something to test is whether all A3DL property/object changes are properly
 reflected in Ter'Angreal.  May not be worth fixing all of them, but maybe some
 of them if people think they need to use that feature.
 
 Others?
 
 What is the state of the Python interface?
 
 Other things we could do are
  * Update the manual with VIP documentation.
  * Make some new worlds. I'm working on a little demo of objects flying 
 around.
  * Is the IRC bridge working properly now?
  * Do all the Visual C projects work?
  * What else?
 
 Then we need to do some test release builds and make sure they work.
 
 During and after the release I might write some short tutorials that focus on 
 how to do
 specific things, probably starting with going through how to make something in
 blender, export it, and load it into a server.  Other ideas are at
 http://interreality.org/wiki/HowTos
 
 Reed
 
 
 
 ___
 vos-d mailing list
 vos-d@interreality.org
 http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


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


[vos-d] Interpolation in TerAngreal

2007-07-08 Thread Reed Hedges

I've been writing some code that makes some objects fly around and Ken's 
interpolation code makes it look nice and smooth.   However, in doing so 
I experimented a bit with position update frequency, wondering what the 
slowest rate I could use is, especially when the velocity I was trying 
to show was constant.  There's effectively a maximum speed that the 
interpolation achieves, so that if you update less than several times a 
second (e.g. once or twice a second), the object has a really jerky 
start-stop motion.

Is there a quick fix for this? Or should we just let that issue be, and 
later add concepts of velocity and acceleration to A3DL?

Would it be possible to add position-interpolation-speed and 
orientation-interpolation-speed properties to Object3D? Or 
position-update-freq-hint and orientation-update-freq-hint?  These would 
be advisory parameters for the interpolation code, that would let it 
choose object velocity in the interpolation.  I like the idea of 
update-freq-hint, because it's not implying anything other than what the 
server side is doing (updating the property periodically). However,  the 
client side would always be one step behind, so it might make things 
look pretty glitchy.

Thoughts?

Reed





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


Re: [vos-d] State of S4 Scripting (Lalo!)

2007-07-03 Thread Reed Hedges

It doesn't have to be in depth about how it works, just shows what it does and
doesn't do (i.e. it just wraps the core vobject and property api, right, not all
the metaobjects [yet]?) and how to go about trying to use it, maybe give some
examples.   How do you build it? (run setup.py?)

Reed


  Do you have any documentation or notes you can add like the great docs
  in s4-scripting?
 
 Why thanks, that's a great idea of something to do until s5 
 materializes.  I haven't written the docs first as I usually do (referred 
 to as design by science fiction in Zope circles), because I was 
 learning s5 as I go, so I wasn't too sure what it was going to look 
 like :-) but I think I know enough to at least write the gist of the docs 
 now.  It may even be possible to recycle the s4-scripting doc structure 
 to some extent.

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


Re: [vos-d] State of S4 Scripting (Lalo!)

2007-07-02 Thread Reed Hedges
Lalo Martins wrote:
 Yes.  There is already a prototype s5-scripting branch somewhere to match 
 Peter's prototype s5 branch, and it looks absolutely beautiful, although 

Is it sftp://interreality.org/home/bzroot/s5-scripting/libs/vos/python? 
Do you have any documentation or notes you can add like the great docs 
in s4-scripting?

Reed

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


Re: [vos-d] State of S4 Scripting (Lalo!)

2007-07-01 Thread Reed Hedges

OK, cool. Maybe we can tar up the Python stuff as a separate download in 
case people want to try it out?   Though lack of message handling might 
be a problem for some people?

So, you plan on moving forward with S5 scripting some time in the 
future, and not really continuoing to work on S4 scripting? (which would 
be basically a dead end.)

Reed




Lalo Martins wrote:
 Also spracht Reed Hedges (Wed, 27 Jun 2007 12:58:40 -0400):
 What is the state of the S4 scripting branch
 (http://interreality.org/home/bzroot/s4-scripting)?  Does the Python
 interface work?
 
 disclaimer: I haven't touched it in months.  I'm answering half from 
 memory, half from a quick look in the last two hours.
 
 The whole scripting extension idea suffers from one conceptual bug, as 
 explained to me by Peter: in-process messaging isn't guaranteed to work 
 in s4, and scripts communicate with c++ entirely by messages.  However, 
 in my tests, it has worked flawlessly; my tests aren't very extensive, 
 though, so it's possible I didn't cover whatever corner case it is that 
 breaks them.
 
 The Python interface mostly works.  You can build script objects from a 
 string or file, and you can execute it.  Missing is the idea of script 
 properties we discussed before.  Binding a script to respond to a 
 message requires a hack.  Also, it should probably be doable from Python 
 as well, and it isn't.
 
 The JavaScript interface segfaults like there's no tomorrow, due to my 
 poor understanding of SpiderMonkey's weird garbage collection.
 
 And the whole thing isn't hooked into the vos build system.
 
 All in all, I'm not sure it's worth fixing; it value would be, at best, a 
 technology preview of the kind of script you'll get (much more safely) 
 in s5, and at that, it won't even be api-compatible.  If anyone really 
 wants it, they can compile from the branch; then again, if you think you 
 want it, you probably actually want s5 :-)
 
 best,
Lalo Martins


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


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

2007-06-29 Thread Reed Hedges

Are there any bugs or real defects in Ter'Angreal or VOS?  I know of two, don't
know if we should fix them:

 * Avatar settings (model/skin) aren't saved (really just an unimplemented
   feature)
 * Objects aren't always removed from the world

Something to test is whether all A3DL property/object changes are properly
reflected in Ter'Angreal.  May not be worth fixing all of them, but maybe some
of them if people think they need to use that feature.

Others?

What is the state of the Python interface?

Other things we could do are
 * Update the manual with VIP documentation.
 * Make some new worlds. I'm working on a little demo of objects flying around.
 * Is the IRC bridge working properly now?
 * Do all the Visual C projects work?
 * What else?

Then we need to do some test release builds and make sure they work.

During and after the release I might write some short tutorials that focus on 
how to do
specific things, probably starting with going through how to make something in
blender, export it, and load it into a server.  Other ideas are at
http://interreality.org/wiki/HowTos

Reed



___
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 Reed Hedges
On Wed, Jun 27, 2007 at 12:29:43PM +0200, Karsten Otto wrote:
 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 :-)

My feeling is that this would be like an optional add-on to a vobject. We would
still have the single master local object with remote proxies (that's still one
logical option; it's the libvos API that calls the remote objects as objects
not proxies and gives them the same interface).  Replication means making
copies of local objects and moving them to different sites, but keeping them in
sync behind the scenes, so a change to one copy gets reflected in the other
copy.   This requires the locking mechanism during that synchronization; locking
would be generally useful as well, even if you're just talking to one object as
a client, not a replicator

IS this kind of thing what you are thinking of Pete?

  I've put together a mockup screenshot here:
  http://interreality.org/~tetron/terangreal%20mockup.png
 
 Looks like Safari! :-)
 I thought you wanted something different than a web browser? In  

Yes, I would skip the back and forward buttons, and the big bookmark
buttons. 

 particular, what use are Tabs here? After all, interacting with a 3D  
 world is about immersion, i.e. you interact with only one virtual  
 reality. 

Well, we could do what some web browsers do, which is hide the tabs UI if
there's only one tab.  You might want to be working in multiple worlds.
SOmetimes immersion can be a pain because it forces the world metaphor on you.
LEt's say your lurking in one world waitingc for people to arrive, but also
participating in the other. Or you are moving objects back and forth between
worlds.  Maybe one of your tabs is the local world within terangreal (i.e. the
one that terangreal starts up in that has some instructions in it)  that you're
using as a scratch space to create objects, then moving them to the other when
done.

 Apart from that, it looks like you intend the interface to be purely  
 2D. Why restrict ourselves to that? Why not a separate 3D overlay,  
 driven by a VOS graph in the same manner as the main 3D world? We  

I agree, having the ability for the client to display local 3D stuff for UI
purposes might be neat, but there's some stuff that just gets hard in 3D. I
think it's a good idea to start off with typical WIMP graphics (using wxWidgets)
so that we can make 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.

 Well, URLs were originally never intended to be visible in the  
 original browser concepts. 

True, but they turned out to be useful :) IN our case, you will only see the top
level world URL (unless you specifically ask for a particular Vobject's URL).

 IMO the entire top half including bookmark buttons sould be the  
 display part of a tool plugin, just like everything else, and should  
 only show up if you select this particular tool.

I agree (though we might want to keep some stuff just built in to terangreal if
it doesn't really need to be a plugin).

 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.



___
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 Reed Hedges
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


[vos-d] State of S4 Scripting (Lalo!)

2007-06-27 Thread Reed Hedges

What is the state of the S4 scripting branch
(http://interreality.org/home/bzroot/s4-scripting)?  Does the Python interface
work?

Thinking about what we should try to include in 0.24 (codename s4 swan song).

Reed



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


Re: [vos-d] development status

2007-06-09 Thread Reed Hedges

Chris is referring here to a proposal for the X3D format/language (new 
version of VRML) to add the sensor nodes mentioned, by the way.

Reed


chris wrote:
 Hi, just a few comments on other status that may interest.
 I have been testing tcp/ip networking with an implementation of the network
 sensor nodes in Flux. I have been able to get the basic test examples to
 work with two linux servers. An example of the nodes is given below. For 
 the
 mass avatar event at siggraph I will be working on modifying the
 communications for UDP.
 
 This raises the possibility of testing vos server with these nodes if ur
 inteterested.
 
 A description of the test examples and MM server is at
 http://www.mediamachines.com/hydra/
 my experience with installing / running the server is at:
 http://planet-earth.org/smam/fluxServerInstallRun.html
 tho u would be wanting to run your own vos server.
 
 I am also running a 2 hr multisuer virtual world BOF at siggraph 
 (August) so
 if you want me to demo vos let me know. I would want something that would
 not require old browser versions, old java etc if possible because I 
 need to
 be able to demo other stuff with current tech as well.
 

___
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-08 Thread Reed Hedges
On Thu, Jun 07, 2007 at 10:02:03PM -0400, Peter Amstutz wrote:
 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.

Seems that this kind of relay or chaining can easily be created just by
creating vobjects to do the relaying. Then you can structure it however you
want.  In doing some hypervos stuff I am creatingsome general purpose listener
tools. Most of them will also be MetaObjects so thy cane be created remotely.


  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.


I think it would be a very useful feature. But we should postpone it until we
have more real world examples of what kinds of conditions would be required.
It's really just an optimization; but I've noticed two things: commonly the 
very first
thing that a listener does (or ought to do) is doa check on a new object's
cname or type, or on a property's data type; and that if you really want to have
dynamic response to vobject changes in an applications, you need to use a couple
layers of the current listeners (e.g. listen for children, then add a type
listener to new children with certain names, then add new listeners such as
property listeners in response to a type change), and it would be easier to make
very dynamic, event driven stuff if some of those more complex conditions were
available out of the box, and done efficiently.

But yeah, wait on this as a future refinement, need more data to determine how
to go about it.

Reed


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


[vos-d] Listener notifications in S5

2007-06-07 Thread Reed Hedges

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. 
   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?

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.

Reed



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


[vos-d] Errors building crystalspace

2007-05-29 Thread Reed Hedges
, csFmtDefaultReaderunsigned char 
 ' is not a base type for type 'csPrintfFormattercsStringFmtWriter, 
csFmtDefaultReaderunsigned char ::IEEEFloatSplitterdouble, unsigned 
int'
./include/csutil/formatter.h: In member function 'void 
csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const 
csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, 
int) [with T = double, Twriter = csStringFmtWriter, Treader = 
csFmtDefaultReaderunsigned char]':
./include/csutil/formatter.h:1411:   instantiated from 'void 
csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1046: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1067: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1108: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1110: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1112: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1411:   instantiated from 'void 
csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1116: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'
./include/csutil/formatter.h:1411:   instantiated from 'void 
csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1136: error: 'struct 
csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char 
 ::IEEEFloatSplitterdouble, unsigned int' has no member named 'mantissa'

 g++ -c -o ./out/linuxx86/debug/libs/csutil/csstring.o -I. 
-I./include -I./include -pipe -Wall -Wno-unknown-pragmas 
-fvisibility=hidden -march=i586 -I/usr/local/include -fno-exceptions 
-fvisibility-inlines-hidden -g3 -DCS_DEBUG -fPIC -DCS_CRYSTALSPACE_LIB 
-Ilibs/csutil/ptmalloc -Ilibs/csutil/ptmalloc/sysdeps/pthread 
-DCS_CONFIGDIR='/home/reed/Interreality/vos/inplace/etc/crystalspace' 
-DCS_PLUGINDIR='/home/reed/Interreality/vos/inplace/lib/crystalspace' 
  libs/csutil/csstring.cpp

...failed C++ ./out/linuxx86/debug/libs/csutil/csstring.o ...
C++ ./out/linuxx86/debug/libs/csutil/snprintf.o
./include/csutil/formatter.h:992: error: non-template 
'IEEEFloatMantissa' used as template
./include/csutil/formatter.h:992: note: use 'csPrintfFormatterTwriter, 
Treader::template IEEEFloatMantissa' to indicate that it is a template
./include/csutil/formatter.h: In constructor 'csPrintfFormatterTwriter, 
Treader::IEEEFloatSplitterT, Tbase::IEEEFloatSplitter(const T, int, 
int)':
./include/csutil/formatter.h:1024: error: 'mantissa' was not declared in 
this scope
./include/csutil/formatter.h: At global scope:
./include/csutil/formatter.h: In instantiation of 
'csPrintfFormattercsFmtDefaultWriterunsigned char, 
csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, 
unsigned int':
./include/csutil/formatter.h:1043:   instantiated from 'void 
csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const 
csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, 
int) [with T = long double, Twriter = csFmtDefaultWriterunsigned char, 
Treader = csFmtDefaultReaderunsigned char]'
./include/csutil/formatter.h:1407:   instantiated from 'void 
csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = 
csFmtDefaultWriterunsigned char, Treader = csFmtDefaultReaderunsigned 
char]'
libs/csutil/snprintf.cpp:32:   instantiated from here
./include/csutil/formatter.h:992: error: type 
'csPrintfFormattercsFmtDefaultWriterunsigned char, 
csFmtDefaultReaderunsigned char ' is not a base type for type 
'csPrintfFormattercsFmtDefaultWriterunsigned char, 
csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, 
unsigned int'
./include/csutil/formatter.h: In member function 'void 
csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const 
csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, 
int) [with T = long double, Twriter = csFmtDefaultWriterunsigned char, 
Treader

Re: [vos-d] Errors building crystalspace

2007-05-29 Thread Reed Hedges

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?

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).

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).

Reed


Reed Hedges wrote:
 Was the crystalspace snapshot updated or changed recently? I'm getting 
 these errors now trying to build it. Is anyone else or is something 
 strange going on with my checkout?
 

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


[vos-d] Embedded properties, string pooling, and search

2007-05-18 Thread Reed Hedges

The planned S5 features of embedded properties and string pooling ought
to make it efficient to search for objects on a site by type or name
(due to string pooling), if the shared strings have pointers back to
their vobjects, right?  Have you implemented string pooling
yet, or what are your plans (have seperate pools for name and type?)

What about searching property values? It would also be nice if they
could be very efficiently searched.

Reed


___
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 Reed Hedges
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).

Reed


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


Re: [vos-d] Wanna help the Mass Avatar Mash?

2007-05-15 Thread Reed Hedges

We don't have specific plans for H-anim and VOS. We haven't designed
how jointed, animateable geometry will work in VOS yet.  Chris is just
keeping us informed about possible things to do (thanks Chris) I think.

At this point, we plan on having a general VRML server for VOS that
exposes a running VRML scene in VOS, but I've been lazy and distracted
by web stuff and haven't worked on it for a while. :)


If anyone is interested in talking about how jointed, animated geometry
will work (for both humanoid avatars and other stuff) will work, go
ahead :)

Reed



On Sat, May 12, 2007 at 12:18:32PM -0700, dan miller wrote:
 can someone sum up what's going on with this project?  Is there going to be
 some sort of H-anim importer to VOS?  Or some other X3D compatibility
 strategy?
 
 -dan 

___
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-11 Thread Reed Hedges


Yeah, so his ideas cut accross all kinds of layers and aspects of
networking.   so I don't think VOS can be THE solution to the problems
he explains, but it can provide a few key tools. Namely it can be a data
storage system, both for originals, and replicated copies, and for
store-and-forward,  If we include stuff like hash fingerprints, and
signing/encrypting data objects, versions, and caching and distributing
copies in a clever way.   

Maybe it could be used for routing search/query/response messages, but maybe
not.  

For discovering resources in a particular local communications
environment (e.g. local wireless network) it's probably best for
something like zeroconf or other broadcast queries.  

Not sure how VOS could fit in with multicast. Not sure if that's
something we should worry about here, since multicast has turned out to
be something of a dead end on the internet, and most local networks as
well that haven't been set up with the possability of multicast in mind.


Reed



On Mon, May 07, 2007 at 05:51:45AM +, Lalo Martins wrote:
 Aaron Bentley posted to the bzr list about a Van Jacobson talk:
  I was watching this talk by Van Jacobson about a new networking
  paradigm, and I started going hey, I know this stuff.
  
  http://video.google.com/videoplay?docid=-6972678839686672840hl=en
  
  Around 37:31, he starts talking about a new dissemination mechanism in
  which you look for named data, rather than having conversations with
  servers.
 
 I can't actually *watch* the talk, though, as stupid google video doesn't 
 work in China.  If anyone is interested, can you please watch, and post a 
 summary?  In particular, how much it's relevant to the way we're already 
 doing things (named data sounds a lot like vobject from my chair).
 
 best,
Lalo Martins

___
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 Reed Hedges

I downloaded a copy of this video if anyone wants it.

Reed


___
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 Reed Hedges
  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.  

The example I was thinking of is this:

Property P has versions P.1, P.2, P.3.  If you have a normal reference
to P, you get P.3, though you know it just as P.  If you write to P, it
creates a new version, P.4, but P (being the current version) is
transparently changed to P.4.  But if you have a reference to
P.2, and you write to it, resulting in a new version P.2.2, it appears
to you that the write didn't work, since you're still looking at P.2.
So P.2 needs to be an alias for most recent version of P.2 in the same
way that P was.  P.3 is then also an alias for most recent version of
P.3, but P.3 doesn't have any derivative versions, so it's just P.3 (or
call it P.3.0 or something).

Reed


___
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 Reed Hedges

I guess each copy, whether changed or not, should have a pointer to its
original.   I wonder if any vobject version should not have it's
versions inside it, but simply have a pointer to it's predecessor (or
the other way around, an object has links to all its derivatives).  Then
you can have different sites for different versions.

Then, while you can't cryptographically verify the derivative, you can
verify its original, and compare them to see if they are the same data
or diferent.

Reed



On Tue, May 08, 2007 at 03:48:38PM -0500, Len Bullard wrote:
 Understood completely and I know how SSL, checksums, asymmetric keys, etc
 work but without the understanding that content drifting away from its
 original sources corrupts means the buyer doesn't understand the technical
 solution is not the whole solution.
 
 In effect, regardless of the wrapper, unless you have the original 1959
 first episode of Rocky and Bullwinkle, you probably can't answer those
 trivia question correctly.  If you don't have the authentication and
 authorization, you don't have access to the original source.  If you don't
 have the digital signature and checksum technology, I can't trust your
 answers without the original sources.  This is the real problem of named
 data sharing.  Otherwise, URIs with registries make the name sharing easy,
 and the rest is authentication, authorization, signatures, etc.   I don't
 think the problem of discoverability is as big as the speaker believes it
 is.
 
 It isn't just trust.  It's verification.  For that, you must have an
 authentic copy of the original source or access which amounts to the same
 thing but if access, you have to prove that.  Names alone won't make that
 happen.
 
 len
 

___
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-06 Thread Reed Hedges
Karsten Otto wrote:
 You cannot really fix this with a don't-interpolate flag,  
 as there is no good place to put one. You could extend the property- 
 update notification, but a lot of properties do not use interpolation  

That's ok. Nothing stops you from adding whatever fields you want to the 
message, and for Terangreal to check for the field for the position 
property. This is why fields have names.

Pete's idea of having extensible method types is interesting though, 
might be useful.

Reed


___
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-26 Thread Reed Hedges
On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote:
 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 another project I've basically implemented this in a set of common Makefile
rules.  It is a bit annoying to debug complex make rules like this but it's 
not that hard my main problem is working in various odd policies and methods 
still around from a previous version of this stuff, and some of the
nonstandard stuff we did there, VOS follows more normal conventions.


 [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?

The problem with this is you can end up with these files being
regerenerated all the time and end up with a zillion revisions, each
with no significant change from the previous.

Reed



___
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 Reed Hedges
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?

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

Reed


___
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-24 Thread Reed Hedges
 
Wow, thanks Ken! 

 
 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...

Try it in a release build.  (both VOS and Crystalspace in release mode).
MSVC puts a lot of extra code in when in debug mode; CS also has a lot
of extra debug utilities that might have been enabled in debug mode.













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


___
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-22 Thread Reed Hedges

Hi Lars, thanks for giving it a try. We have not tried the current
version of vos on Solaris yet but would like to make it work there (the
libraries and server at least).

Are you using 0.23, or the development version (source control
repository snapshot or checkout)?

What version of autoconf is being used, and what version of automake?

Reed



Lars O. Grobe wrote:
 Hi, did anyone manage to build VOS on Solaris? Here it ends:
 
 libs/vos/vip/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined.
 libs/vos/vip/Makefile.am:1: The usual way to define `LIBTOOL' is to add
 `AC_PROG_LIBTOOL'
 libs/vos/vip/Makefile.am:1: to `configure.ac' and run `aclocal' and
 `autoconf' again.
 
 So I would be curious if anyone managed to build and install VOS on Solaris.
 

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


[vos-d] S5 and single-thread option

2007-04-20 Thread Reed Hedges

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).

Reed


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


[vos-d] server requirements

2007-04-18 Thread Reed Hedges


In a different forum, Hellekin Wolf asked:

 The server issue mentioned above makes me think of the requirements for
 running a VOS world. Do I need hardware graphics or is it only for the
 client side? 

A server does not need any graphics hardware.  Many servers in fact are
just providing data so you don't even need a fast processor, though
things tend to run is many threads so the more processors the better.  The
current design does use a lot of memory if you have lots of objects, though 
changing that is a big priority for the next big version (S5) -- a really 
good threading model is also of course planned as Pete has been telling us 
about.

For reference, interreality.org is an AMD 64 X2 dual core, 2GB RAM and it runs
with less than 1% load; we anticipate being able to run several (5-10) small 
worlds
on it as well as the website.  It replaced a 300 Mhz Pentium II with less than 
512
MB memory!! It ran pretty well, though memory was tight. I have a 1.5
GHz AMD at home and it also runs fine.

In the future we may have server modules that do dynamics and physics
simulation for everyone, that will require a fast processor, or possibly
a coprocessor.  Also, servers that need to do more computation will
obviously require faster processors. 

The client requires some kind of 3D graphics hardware to run well.
Crystal Space does have a software-only renderer though it is not very
actively maintained. Supporting that software-only renderer is something
that we'd like to do in Terangreal (the client) eventually.

Of course, it's also technically possible to create Vobjects within 
Terangreal (by modifying terangreal's code) that can be a server to 
other clients, due to the flexibility of VOS :) (You can also just
create objects in the mesh tool, this is a good way of experimenting
with stuff.)

The server framework is called omnivos.  If you look at (vos/apps/omnivos)
you'll see that it's like 15 lines of code :)  It mainly just loads
plugins.  Run it with one of the example configuration files like this:
omnivos -c example.xod -nofork -o -.

Reed


___
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 Reed Hedges



On Tue, Apr 17, 2007 at 07:27:21AM +, Lalo Martins wrote:
 One problem I have with the pure-js version is the nature of HTTP; either
 the browser would need to keep a persistent connection to the server, like
 some web chat rooms do -- which is error prone (hard to recover from a
 disconnect) and makes the deserialisation a bit more complicated -- or it
 would have to poll, which sucks for a number of other reasons.


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.

Reed


___
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 Reed Hedges


This would be great for people who primarily want to just chat or be
present in the world while doing other work, so they don't want the full
3D world.

It would also make it possible for blind people to interact in the 3D
world.

Reed



On Tue, Apr 17, 2007 at 01:54:23PM -0400, Peter Amstutz wrote:
 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.

___
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 Reed Hedges



 scenery part). Unfortunately, viewpoints usually have no navigation  
 links between them. So for what you want to do, you need a  
 combination of both.
 
 This requires some work, but VOS is flexible enough to support all this.


Yeah, you would just have the waypoint object type have child links to
other waypoints. You would then combine it with the viewpoint type
which provides the 3D position, orientation, and other spatial info. Or
those two aspects could just be contained in one  object type.

Having a set of exits from a viewpoint might be useful in 3D as well,
as a way to help people navigate 3D spaces.



 You need exit lables on the navigation edges for this. 

This is what the contextual names on child links are for :)


  Gonzo(3d) goes south to the entrace to the Pyramid.
 
 In contrast, this is terribly complicated. Deriving the intention/ 
 activity of a user (thats what you have here) from its raw movements  


We can explicitly represent it by giving the waypoint object type a
child that's a container for avatars who are at that waypoint.


 A few other text-user commands that may be handy:
 
 follow user - move the text-user's avatar to wherever another  
 avatar (text or 3d!) is moving to.
 
 face user - turn the text-user's avatar to face another one. You  
 can also do this automatically if you detect a corresponding speech  
 pattern like kao: are you there?
 
 approach user - like face, but also move the avatar close to the  
 target.


These behaviors would also be useful in 3D too.


Reed


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


[vos-d] Thinking about Javascript

2007-04-16 Thread Reed Hedges

Is anyone here familiar with Javascript much? 

I'm wondering what kind of networking tools are available from
Javascript. I've been reading about a thing some people call Comet,
(http://alex.dojotoolkit.org/?p=545) which basically a publish/push 
model for the server to update pages live. It looks like it uses
a JSON protocol called Bayeux 
(http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt).
I've been thinking about how we can push VOS events out to the web
browser, and I'm wondering whether Javascript running in the browser
could use a VOS runtime (running in a plugin??) with JS bindings, or 
if it makes more sense for the server to translate the events into 
a more web-specific protocol that would be interpreted entirely by
Javascript code shipped along with the page (even perhaps including all the 
object-to-XML logic in the server as well, like Hypervos).

Thanks

Reed


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


Re: [vos-d] terangreal changes

2007-04-13 Thread Reed Hedges
On Thu, Apr 12, 2007 at 10:29:35PM -0400, Peter Amstutz wrote:
 On Thu, Apr 12, 2007 at 09:26:09PM -0400, Reed Hedges wrote:
 
  * Change mouse cursor to reflect what clicking will do (i.e. 
  differentiate between mouselook/move modes; change when over a hypercard 
  or clickable)
 
 Yea, that would be useful.
 
  * If you click some mouse button on an object it becomes selected
  * In the future, could show a panel to edit properties of selected 
  object, or create new objects attached to it in scenegraph fashion, or 
  whatever
 
 How do you differentiate between I'm clicking on this to activate it 
 and I'm clicking on this to edit its properties?  

What do you mean by activate? You mean if the objcet has the clickable
type? Different mouse clicks probably.  Or have modes.  

 
  * If a selected object has the ui:actions type that I added recently, 
  then display those in a side panel as buttons
 
 I'll have to take a look at it -- sounds like a generalization of 
 misc:clickable perhaps?  So instead of I can accept click messages you 
 say I can accept messages X, Y and Z and specify that X is the 
 default message for clicking.

Yes but there's no default currently.  A ui:action is like a macro for
sending a message to an object that describes the message in a user
friendly way.  It's implemented in mesh, it prints a list of actions for
the current object, and if there's ann action called foo you just say
do foo and it sends whatever message is behind foo to the object.

 
  * Some way to show/hide sets of objects in the world, or change their 
  properties together as a group (e.g. alhpa to make them fade in and 
  out).  These groups could be called layers or groups.  This would be one 
 
 This sounds kind of complicated, although I agree it could be useful.  
...
 Let me also point out that you probably shouldn't kill yourself with 
 crazy new ter'angreal features; the only reason I'm working on it is to 

I don't think it would be too hard.  It's just something I thought of
that would be unique and interestincg to show off to people. I was
actually thinking of making the layers be metaobjects so others would
share your layer selection, useful for collaborative work.

Do you think that most of the Terangreal GUI (wx) will be easily transferred
to s5, even if the A3DL CS plugin guts are torn out and redone?

(Will you post a comprehensive description of A3DL changes in s5 later,
like you have been doing for VOS in s5?)

When we do demos we actually should have two laptops so people can see
what in the scene is shared (and what's not).

Reed


___
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 Reed Hedges
Peter Amstutz wrote:
 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. 

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

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

Well, not important I guess.

Reed


___
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 Reed Hedges

So messages between local objects will be serialized and passed like 
remote messages, rather than being method calls?   Is that overhead a 
concern?

If so, maybe an optimization would be to have a message format that just 
packs native machine format arguments into the message in the same order 
as the method handler arguments (omitting the field labels)?

Reed

___
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 Reed Hedges
Peter Amstutz wrote:
 On Thu, Apr 12, 2007 at 08:16:59AM -0400, Reed Hedges wrote:
 So messages between local objects will be serialized and passed like 
 remote messages, rather than being method calls?   Is that overhead a 
 concern?
 
 It is a concern, although I'm don't think I would call it 
 serialization since there is no data conversion happening, it is just 
 copying the method parameters into a temporary message structure, 
 possibly copying the message if it needs to be queued, and then copying 
 those parameters out of the message structure onto the stack when we get 
 around to actually calling the method.
 
 If so, maybe an optimization would be to have a message format that just 
 packs native machine format arguments into the message in the same order 
 as the method handler arguments (omitting the field labels)?
 
 At the moment it does still include the field labels, but the labels are 
 just pointers into the string table, so they are cheap to copy as well.


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?


 
 I think it is important to retain the field labels and data types, 
 because once the message is constructed we don't know if it is going to 
 stay in process, be passed to a scripting VM or be sent out over a 
 socket.

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).

Actually sticking to always having named fields is a good thing.  They 
tend to come in handy a lot.  (It's one slightly annoying part of 
XML-RPC in my opinion.)

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.

 
 On that note, one of the things I want to do is come up with a set of 
 rules for what to do when an incoming message has slightly different 
 parameters from the method signature of the target

Good idea.  (Other things that are also possible are to have hooks to 
filter and reform messages, or relay through a Vobject which does 
that.  This kind of thing will be pretty easy to do and will make it 
possible to hook together different applications.)

 
 The rules I'm thinking of would be along the lines of:
 
  - If the message has an unrecognized field tag, but all other fields 
 can be matched, ignore the unrecognized field


Yes, important.

  - If the message fields are in a different order than the method 
 expects, reorder the message fields to match the method fields.

Yes, very very important. We shouldn't rely on the order at all really.


 
 And so on (these are just examples off the top of my head).

same for int-float conversions.


Basically, we should expand what the Message class can do.

Here's a rough outline of how it might look:

class Message {
   size_t len; char *data; // suitable for sending over the network as is?

   string method;

   string getField(string fieldName);
   int getIntField(string fieldName);
///...etc...
}

Completely made up this:
otd
   structdef name=struct1
field required name=a type=int /
field required name=b type=int /
field required name=c type=array(float) /
   /structdef
   structdef name=point
   field required name=x type=float /
   field required name=y type=float /
  /structdef
   message method=example-message
 field required name=foo type=string /
 field optional name=bar type=array(int)/field
 field optional name=complex type=struct1 /
 field optional name=points type=array(point) /
  /message
/otd


class ExampleMessage : Message {
typedef struct {
int a;
int b;
int c;
} struct1;
typedef point {
double x;
double y;
} point;
char *foo;  // pointer into Message::data
int *bar;// pointer into Message::data. Easy to access, but need 
to use a function to insert:
void insertIntoBar(int v);
size_t *bar_size;  // pointer into Message::data
struct1 *complex;
point *points;
size_t *points_size;
void insertIntoPoints(ExampleMessage::point v);
};





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


Re: [vos-d] misc:search questions

2007-04-07 Thread Reed Hedges
Ken Taylor wrote:
 the fact that you guys seem to be allergic to comments doesn't
 help either ;) (i jest! i jest ... sorta)
 

Just Pete.

But he wrote most of the code.

Reed


___
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 Reed Hedges
Peter Amstutz wrote:
 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.
 

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 :)

 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.

 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.

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).

Reed


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


Re: [vos-d] keyboard vs. wimp interface for 3d

2007-04-03 Thread Reed Hedges
Karsten Otto wrote:
 Interestingly, while it has buttons that trigger actions, I mainly  
 used them as a quick way to arrange keyboard shortcuts during normal  
 gameplay. The only time I ever used the interface in a traditional  
 way was for complex actions like trading items. Actually this is  
 quite similar to my Blender experience - it drove me crazy when I had  
 to use the menus, but was a breeze once I knew the keyboard  
 shortcuts. Not sure if there is a lesson there...

We need these keyboards--
http://www.artlebedev.com/everything/optimus/

(and affordable!)

Reed



___
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-03-31 Thread Reed Hedges

Tony says more details about their system and protocol will be available
 later in April (after they present it at the Web3D Symposium).

With s5 we've talked about tweaking the A3DL object model a bit for
various reasons. One thing we can do is make A3DL line up with
X3D/VRML a bit better, which would help with loading VRML into a VOS
server.

Another possability I'd be interested in looking at is if SWMP is
suitable for plugging in as an alternative transport protocol -- I don't
think the documentation talks much about it, and we've never really done
to much with the idea, but we've always had the idea that VOS objects
could communicate in different ways other than just over the network
using a protocol like VIP. E.g. different sites in a cluster of
computers could communicate much faster through shared memory or
something like that.  Sites could also talk to each other using
different protocols.  Not sure yet how to bridge to completely different
 multiuser 3D systems but at some point we might see if it's possible.

Reed




Reed Hedges wrote:
 
 
 
 Subject:
 [www-vrml] Flux Worlds Server Announcement
 From:
 Tony Parisi [EMAIL PROTECTED]
 Date:
 Fri, 30 Mar 2007 14:08:27 -0700
 To:
 'x3d-public list' [EMAIL PROTECTED], 'www-vrml'
 [EMAIL PROTECTED]
 
 To:
 'x3d-public list' [EMAIL PROTECTED], 'www-vrml'
 [EMAIL PROTECTED]
 
 Return-path:
 [EMAIL PROTECTED]
 Envelope-to:
 [EMAIL PROTECTED]
 Delivery-date:
 Fri, 30 Mar 2007 17:23:26 -0400
 Received:
 from server5.outofcontrol.ca ([67.15.54.3] helo=web3d.org) by
 interreality.org with esmtp (Exim 4.63) (envelope-from
 [EMAIL PROTECTED]) id 1HXOZC-0004hj-49 for
 [EMAIL PROTECTED]; Fri, 30 Mar 2007 17:23:26 -0400
 Received:
 (from [EMAIL PROTECTED]) by web3d.org (8.13.1/8.13.1) id l2UL8b5q002738 for
 www-vrml-outgoing; Fri, 30 Mar 2007 17:08:37 -0400
 X-ClientAddr:
 68.142.198.206
 Message-ID:
 [EMAIL PROTECTED]
 X-YMail-OSG:
 YdctFGYVM1n.8kk5AKF_NK_BHTa6B4bhKOAcp60Dh6ruxknPqKH_FaSL8MKh.mRJL3H472LKdmQMt_3gT73yu_cgkQ--
 MIME-Version:
 1.0
 Content-Type:
 text/plain; charset=us-ascii
 Content-Transfer-Encoding:
 7bit
 X-Mailer:
 Microsoft Office Outlook, Build 11.0.6353
 X-MimeOLE:
 Produced By Microsoft MimeOLE V6.00.2900.3028
 Thread-Index:
 AcdzD3XDRb6swz8uR6SHIti2zgRz2w==
 X-OutofControl-MailScanner-Information:
 Please contact the ISP for more information
 X-OutofControl-MailScanner:
 Found to be clean
 X-MailScanner-From:
 [EMAIL PROTECTED]
 Sender:
 [EMAIL PROTECTED]
 Precedence:
 bulk
 X-SA-Exim-Connect-IP:
 67.15.54.3
 X-SA-Exim-Mail-From:
 [EMAIL PROTECTED]
 X-Spam-Checker-Version:
 SpamAssassin 3.1.7-deb (2006-10-05) on interreality.org
 X-Spam-Status:
 No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO
 autolearn=ham version=3.1.7-deb
 X-SA-Exim-Version:
 4.2.1 (built Tue, 09 Jan 2007 17:51:29 +)
 X-SA-Exim-Scanned:
 Yes (on interreality.org)
 
 
 Folks,
 
 We've been up to something over here - thought I would tell you about it
 before you heard it on the street.
 
 Media Machines has been developing a multi-user server based on a new
 protocol that we intend to put out into the open. We have dubbed it Simple
 Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is
 to work with Web3D and potentially other organizations to standardize SWMP.
 We will also supply a basic open source implementation. Our overriding
 goal-- one that we are pursuing with total passion and vigor-- is to create
 an open infrastructure for the Metaverse. 
 
 We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds
 is currently in alpha test. While the product is still several weeks away
 from beta test, we announced it yesterday with the goal of attracting early
 signups for the beta. We are also integrating a prototype of the new X3D
 networking nodes being developing by the Networking Working Group, right
 into Flux Player. The results look promising.
 
 Anyway, here is the announcement. We would love to have you be part of the
 beta when it's ready!
 
 http://www.mediamachines.com/press/pressrelease-03292007.php
 
 Remember, the Metaverse needs open protocols. Without them... everything
 else is Just a World.
 
 Yours virtually,
 Tony
 
 -
 Tony Parisi  415-902-8002
 President/CEO   [EMAIL PROTECTED]
 Media Machines, Inc.www.mediamachines.com
 
 Add 3D content to your web page with the Flux Player. 
 Go to www.mediamachines.com to upload and share your 3D content.
 -
 
 
 
 
 -
 for list subscription/unsubscription,
 go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html

Re: [vos-d] s5 design overview

2007-03-30 Thread Reed Hedges
 put this command or any other commands in
~/.mesh/meshrc).


Reed


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


[vos-d] Flux Worlds Server Announcement

2007-03-30 Thread Reed Hedges
---BeginMessage---
Folks,

We've been up to something over here - thought I would tell you about it
before you heard it on the street.

Media Machines has been developing a multi-user server based on a new
protocol that we intend to put out into the open. We have dubbed it Simple
Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is
to work with Web3D and potentially other organizations to standardize SWMP.
We will also supply a basic open source implementation. Our overriding
goal-- one that we are pursuing with total passion and vigor-- is to create
an open infrastructure for the Metaverse. 

We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds
is currently in alpha test. While the product is still several weeks away
from beta test, we announced it yesterday with the goal of attracting early
signups for the beta. We are also integrating a prototype of the new X3D
networking nodes being developing by the Networking Working Group, right
into Flux Player. The results look promising.

Anyway, here is the announcement. We would love to have you be part of the
beta when it's ready!

http://www.mediamachines.com/press/pressrelease-03292007.php

Remember, the Metaverse needs open protocols. Without them... everything
else is Just a World.

Yours virtually,
Tony

-
Tony Parisi  415-902-8002
President/CEO   [EMAIL PROTECTED]
Media Machines, Inc.www.mediamachines.com

Add 3D content to your web page with the Flux Player. 
Go to www.mediamachines.com to upload and share your 3D content.
-




-
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html

---End Message---
___
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-22 Thread Reed Hedges

We don't know what our niche is yet.  We have one main domain (3D)
and a secondary domain (Web) but there might even be others.
Actually when we first began this several years ago, we knew  someone
who knew someone intersted in building factory tracking systems, though
we ended up not really considering that at the time.  At one point I
wanted to do wireless self-organizing sensor networks-- I still think
that will be an emerging realm of innovation but I know that VOS is
not a good fit for its requirements.

I think we have some vague ideas on what we want our specific niches 
within 3D to be-- Peter and I may not even be able to explain it 
well yet.

So, we're just trying to implement what we can, so we can show it to
people and eventually find a niche.

Reed


On Thu, Mar 22, 2007 at 11:22:10AM -0500, Len Bullard wrote:
 The urge to focus on one single application is normal, but if you are
 building a toolkit such as VOS, it would be deadly.  You're doing the right
 thing, but it violates two of the web myths: easy and simple.  Simplistic
 analogies will sell it perhaps, but don't get trapped by your own press.
 VOS won't be a tool everyone can use.  The niche that can can do a lot with
 it.  I think that is Reed's point, yes?
 
 len

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


Re: [vos-d] Upcoming changes: factory, actions.

2007-03-21 Thread Reed Hedges
Ken Taylor wrote:
 Cool! I was actually thinking the other day that being able to select and
 inspect objects in Ter'Angreal would be useful and not super-difficult to
 implement on the current architecture. I like the ui:actions object as a
 sort of scripting approximation, though i'm assuming it will probably be
 supplanted by a more general user-scriptable-actions mechanism in future
 versions.

Yes. It's meant to also complement server-side scripts. E.g. you make a
script that can be triggered by some random message you invent. Then you
can add an action that will let the user send that message with a button
click.

 
 What also would be neat is an advanced mode which allows you to edit the
 properties on objects directly (assuming you have permission) -- including
 adding new child objects. Allow this to be done on the sector (or a
 sub-space of the sector, once that is added to a3dl), and you have basic
 real-time geometry building.

Yes, we need that.  I've been thinking about that a lot.  We had a
simple one back in the day, just did a few 3D properties.   I think what
we'll try to do is have a little editing pane/dialog in TerAngreal, but
it will be provided by a library, so we will also have a more complex
standalone editor too.

This is another place that OTDs could be useful: if the object editor
knows what types of properties to expect, then it can create useful GUI
controls for them in a generic manner.

 
 Of course, before allowing all users the ability to add objects, it would be
 good to hack in some quotas/limits and auto-destruction of old objects, lest
 your server grind to a halt from a malicious user.
 
 But perhaps I'm thinking too far ahead at the moment ;)

Yeah, I think we'll worry about that later. I'm pretty sure we'll be
able to implement all kinds of quota or throttling access control
behaviors in server plugins in the future, when they become neccesary,
as long as we keep Identities in use, and also perhaps more
robust/certain remote-site identification that might be coming in s5 IIRC??

Reed




___
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-17 Thread Reed Hedges

 
 Another thought: does your derived class *have* to inherit Base virtually?

Yes, basically. Well, in one case it doesn't and calling the method in 
the base class to register the handler works.  In another case it has to 
be virtual.

Maybe I can find a way to reorganize things to avoid it.

Reed

___
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 Reed Hedges
Peter Amstutz wrote:
 On Thu, Mar 15, 2007 at 06:15:39PM -0400, Reed Hedges wrote:
 
 The reason I ask is that I want to load some 3D objects from a COD file,
 but then insert some non-3d children into one of those objects, and
 extend its types. This is the kind of thing that VOS is all about :)
 Practically speaking, I want to be able to re-export the 3D COD from
 Blender and clobber it while keeping my non-3d extensions seperate.
 
 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 /



 
 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?

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

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.

Reed


___
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 Reed Hedges
Peter Amstutz wrote:
 Well, the idea was more to support the ability to import other file 
 formats (X3D comes to mind, although it's maybe not a good example since 
 it's really an example of how not to design an XML schema) using a 
 straightforward XSLT transform.  Of course, we haven't yet tried writing 
 any transforms so I don't know if it's actually feasable.

I wrote a transform that goes from Doxygen's XML output to XOD.  It was
just an excersise to finally learn XSLT, which turns out to be really
easy.   I haven't tried it yet, I want to figure out how to be smart
about inventing positions for 3d objects automatically.

Reed


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


Re: [vos-d] X3D

2007-03-16 Thread Reed Hedges
Len Bullard wrote:
 I will move on to X3D because eventually I will need some
 of the new features like Inlines with interfaces and bits like the Keyboard
 Sensor, the upcoming Network Sensor and the physics engine, or the
 Nice-to-Haves like the Boolean Sequencer that I can replicate in script but
 a node is easier.  For now, I am building in VRML97 where the weather suits
 my clothes.

Fortunately, it sounds like some good GUI editors are coming out (like
Flux studio).I never did manage to find a really good GUI tool for
building VRML97 that was really focused on VRML and supported all of it,
though I was only looking at the free ones.

(Back when I was able to actually do 3D for a job I ended up exporting
VRML from a simple modeler called AC3D and then mucking about in it by
hand slightly.)

Reed

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


  1   2   >