[vos-d] vos-s5.3

[Reed Hedges]

Attached is a patch that

1. adds a file called BUILD.txt that starts to give some instructions on 
how to build vos, including a list of dependencies you can install if 
you don'nt want the scons script to try downloading and building stuff.


2. links to libpthread when testing crypto++

vostest runs successfully for me.  Pete, can you describe what the other 
programs you've started are for and how to run them?


Reed


=== added file 'BUILD.txt'
--- BUILD.txt   1970-01-01 00:00:00 +
+++ BUILD.txt   2009-02-17 18:13:01 +
@@ -0,0 +1,92 @@
+
+
+Building VOS
+
+
+To build VOS, run the scons.py script:
+
+ ./scons.py
+
+or
+
+ python ./scons.py
+
+Targets built will be found in various subdirectories of debug/build. You will
+need to add directories containing shared libraries to your system dynamic
+library path (LD_LIBRARY_PATH environment variable on Linux, DYLIB_LIBRARY_PATH
+on Mac OSX, PATH on Windows).
+
+Build options
+-
+
+TODO what options can we give to scons??
+
+Use "./scons.py tests" to build tests from src/tests
+
+
+Supported Platforms
+===
+
+Debian Linux 'sid' with GCC 4 and GNU dev tools
+Windows XP with ???compiler???
+Windows Vista with ???compiler???
+Mac OSX 10.?? with ???compiler???
+
+
+Build Dependencies
+==
+
+The following "third party" libraries are required to build VOS.
+Python is required to run the scons build system. Scons will determine 
+whether each library is already installed on the system, and if not,
+will try to obtain it from the net and build it.  It has several
+ways to obtain them; you can select your preferred method using 
+the DOWNLOAD_OPT variable.  The methods are bzr checkout,
+hg (mercurial) checkout, install on Debian using apt-get, or downloading
+a tarball snapshot using wget. 
+
+Python 2.4+ http://www.python.org
+libicu
+libboost_thread http://www.boost.org
+libboost_system
+libboost_regex 
+libboost_signals
+libboost_program_options
+boost asio
+boost spirit
+boost_unit_test_framework
+Crypto++
+xerces
+pkg-config 
+Qt 4.5+ http://www.qtsoftware.com
+Open Scene Graph
+
+Optional:
+bzr 1.5http://www.bazaar-ng.org
+Mercurial
+wget
+
+
+Debian/Ubuntu
+-
+
+Install the following packages with apt-get:
+
+python libicu-dev libboost-thread-dev libbost-system-dev libboost-regex-dev 
libboost-signals-dev libboost-program-options-dev libboost-dev 
libboost-test-dev libcrypto++-dev libxerces-c2-dev pkg-config libqt4-dev 
libopenscenegraph-dev
+
+
+Fedora
+--
+
+todo
+
+Windows
+---
+
+todo
+
+
+Mac OSX
+---
+
+todo

=== modified file 'scripts/cryptopp.py'
--- scripts/cryptopp.py 2009-02-12 02:01:58 +
+++ scripts/cryptopp.py 2009-02-17 16:21:31 +
@@ -38,7 +38,7 @@
 context.sconf.env['CRYPTOPP_CPPDEFINES'] = ['CRYPTOPP_IMPORTS']
 return thirdparty.TryCompileAndLink(context, 'Crypto++', 'CRYPTOPP_', 
'.cc',
 headers=['cryptopp/cryptlib.h'],
-libraries=['cryptopp'])
+libraries=['cryptopp', 'pthread'])
 
 def checkCryptoPP(context):
 return thirdparty.configureDependency(context,

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

[vos-d] [Fwd: Nokia to License Qt Under LGPL]

[Reed Hedges]

 --- Begin Message ---
Dear Qt User:

Nokia is pleased to announce that with the release of Qt 4.5 you will
be able to use Qt under the Lesser General Public License (LGPL)
version 2.1 terms. When released in March 2009, Qt will be made
available under three licensing options: Commercial, LGPL and GPL.
Prior versions of Qt are not impacted by this announcement.

Nokia is committed to Qt and its continued development. By offering Qt
under LGPL version 2.1 license terms alongside today’s licensing
options Nokia hopes to:

- facilitate wider adoption of Qt across industries, desktop, web and
embedded platforms.
- establish Qt as a de facto standard for application development.
- receive more valuable feedback and increased user contributions to
ensure that Qt remains the best-in-class, cross-platform framework.
- extend Nokia’s existing platform commitment to the open source
community.

By offering a cost-free LGPL license as well as commercial and GPL
licenses to Qt, you can choose the license model that best fits your
development requirements.

Irrespective of which license model you choose:

- Qt Software is committed to continuing to provide our customers with
the same level of professional support, services and regular releases
you have come to expect of Qt Software.
- We will continue to actively develop Qt, and with a greater degree
of cooperation with the community through a new contribution model, we
hope to make Qt even more valuable to our users.

For more information on the introduction of the LGPL license and what
this means for you, please consult the Frequently Asked Questions
section on www.qtsoftware.com.

Best regards

Tom Miller
Director of Sales
Nokia, Qt Software


__
If you no longer wish to receive these emails, please reply to this
message with "Unsubscribe" in the subject line or simply click on the
following link:
http://cts.vresp.com/u?a3eb360520/6d6eec7684/6ad3c3e

__
This message was sent by Nokia, Qt Software using VerticalResponse

Nokia, Qt Software
Sandakervn 116
(P.O. Box 4332 Nydalen, NO-0402 Oslo)
Oslo, Oslo  NO-0484

Read the VerticalResponse marketing policy:
http://www.verticalresponse.com/content/pm_policy.html

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

[vos-d] How databases hurt scalability

[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

[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

[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

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

[Reed Hedges]

First two graphs, averages of number of users on the channel.

Not a great gauge of activity or when the best time to be on the 
channel, since most of the activity on #vos is just lurking.


Since there's a small number of users, we can look more closely at who 
is on when I think.  I think charting that is beyond the capabilities of 
gnumeric though... will need to think about that.


I'm tempted to just put some basic graphic features in my Qt UI 
prototype and write a function to load a text file into dummy vobjects 
for use in that UI...


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] babies

[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.6uo36zg5&x=0&h=1&y=bnzfdn&localeid=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

Re: [vos-d] Web Site

[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

[vos-d] Web Site

[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

[vos-d] Overview of Topicscape

[Reed Hedges]

A tool that combines a 3D representation of a map or graph, and different views
for documents etc. in the tree.

http://www.informationtamers.com/Personal-journey-in-information-management.html

Second page starts talking about visual representations.

Reed


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


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

[vos-d] some work in designing entity-relation schemas

[Reed Hedges]

This is about schemas for describing data shared between applications, was
developed as part of WinFS for Longhorn though this part of it wasn't eventually
actually included in Vista.

I think I can download the full paper if anyone wants it.

http://portal.acm.org/citation.cfm?doid=1247480.1247532

Compiling mappings to bridge applications and databases
  International Conference on Management of Data archive
  Proceedings of the 2007 ACM SIGMOD international conference on Management of
  Beijing, China
  SESSION: Data cleaning and integration table of contents
  Pages: 461 - 472  
  Year of Publication: 2007
  ISBN:978-1-59593-686-8
  Authors   
  Sergey MelnikMicrosoft Research, Redmond, WA
  Atul AdyaMicrosoft Corporation, Redmond, WA
  Philip A. BernsteinMicrosoft Research, Redmond, WA

  ABSTRACT

  Translating data and data access operations between applications and databases
  is a longstanding data management problem. We present a novel approach to this
  problem, in which the relationship between the application data and the
  persistent storage is specified using a declarative mapping, which is compiled
  into bidirectional views that drive the data transformation engine. Expressing
  the application model as a view on the database is used to answer queries,
  while viewing the database in terms of the application model allows us to
  leverage view maintenance algorithms for update translation. This approach has
  been implemented in a commercial product. It enables developers to interact
  with a relational database via a conceptual schema and an object oriented
  programming surface. We outline the implemented system and focus on the
  challenges of mapping compilation, which include rewriting queries under
  constraints and supporting non-relational constructs.


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

Re: [vos-d] s5 properties proposal

[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

[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

[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

[Reed Hedges]

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



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

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

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

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

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

class PropertyVobject : Component, PropertyCore
{
}


class Site {
  set entities;
}



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

I know this is simplified but does this make sense?

Reed



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

Re: [vos-d] s5 vobject properties

[Reed Hedges]

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

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


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

?


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

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


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

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

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

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

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

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


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

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

Reed



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

[vos-d] More on the web site

[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

[vos-d] Wiki editing fixed

[Reed Hedges]

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

Let me know if there are any problems.

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

Reed

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


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

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

[Reed Hedges]

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

Does anyone have any input on choosing a toolkit?



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

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

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

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

[Reed Hedges]

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


Thanks, fixed.

Reed



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

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

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

[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] More new S5 classes/concepts

[Reed Hedges]

I've updated http://interreality.org/wiki/S5 with this information. 
Peter, can you please check it and fix it if anything is inaccurate?  I 
did elide some of the minor details, just in the interest of clarity.

Some minor comments below about naming things to be less confusing to 
think about if you want...

Also it might help people understand how VOS works if the libvos code 
was seperated a bit into directories or the files were named according 
to use 'layers'...  E.g. I don't think people need to the code 
generation infrastructure much?


>>ConstructorFunctionWrapper
>>ConstructonFunctionFunctor
>>ConstructorFunctionComponent
> 

rename ConstructorFunction* to Constructor*? Are there other 
ConstructorThings?


>>The host's factory (i.e. from Host::getFactory())
> 
> In order to create new objects attached to a particular Site, you use 
> the Factory object on that site (Hosts are a special type of Site.)  
> This is the basically the same as s4 with Site::createVobject(), but 
> separating the Factory out to a distinct Vobject.
> 

Would it make sense to hide all this 
(Factory/Constructor/Implementation) with a few more convenient static 
methods in Host, at least to address the most common needs of creating 
vobjects.   (While users who need to do more advanced things like add 
new types etc. can access the factory.)   We ended up doing something 
similar in S3/S4 I think?


>>DataTypeWrapper
>> ParentChildLinkWrapper
 >> ClassWrapper

etc.

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.

Or DataType is a subclass of DataTypeBase which overloads DataTypeBase 
to add the Wrapper stuff? (Maybe it also inherits from a Wrapper base 
class?)

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.

The second "use level" is defining new types, primarily component types.

And then, beyond that, users would maybe need to deal with Interface and 
Implementation objects.   I.e. maybe adding support for a new language 
or something?   Or ever?

...

>> What does it mean to append children to the local host?  I am guessing 
>> this is so the object doesn't get destroyed (by reference count/garbage 
>> collection), and so you can also obtain it by name later?  Do all 
> 
> The local host is a special site.  Sites now have a root child list 
> which is like a root directory.
> 
>> objects need to be added to the local host (like they were all children
>> of the local site in s4)? And if so, why not do that automatically when 
>> created?
> 
> When created, vobjects must be associated with some site (such as the 
> local host).  The intention is that in order for the vobject to be 
> persistant, it must be connected to the vobject structure so there is a 
> path from the root to the vobject.  Vobjects which are not connected to 
> the root are not persistent.
> 

So a factory that you obtain with Host::getFactory() is not associated 
with the local host really?

Could we integrate the adding of a Vobject to the local host into the 
creation of a vobject (as above wrt. factory).

I.e. I'd like creation of Vobjects on the fly to be easier... it really 
should be even easier than in S4, which is  sort of complex and hard to 
remember what function to use when...

Reed


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

Re: [vos-d] templates/macros

[Reed Hedges]

Peter Amstutz wrote:

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


This is definitely something we need.  It ought to be very 
straightforward to implement as a component type, using listeners.

But let's not add any more tasks like this right now, let's get the VOS 
core working first (including listeners)

Reed


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

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

[Reed Hedges]

Lalo Martins wrote:

> So.  How it works is basically... MVC.  There is a View Context class 
> called WebRequest.  (This is in libvos, in case someone wants to write 
> another implementation of hypervos, say, stand-alone, IIS, whatever; 

Why is this in libvos? It should be in a seperate library.


> 
> (Now, on my original design, web pages would be "transient views", 
> meaning, there is a ViewImplementation that writes to the WebRequest, but 
> it never actually returns a View.  This feature has been lost on Peter's 
> implementation, but we plan to bring it back later on; just not a very 
> high priority.  For now, by not attaching the View to any site, the 
> ViewImplementation can make sure it's collected in the next gc cycle.)

How expensive is it to create a new View like this for every web request?

I see in mod_vos.cc that it calls createView() on the result of 
findCompatibleViews().  [What does findCompatibleViews do??], is it 
somewhere in that call that it writes the HTML (or whatever) output to 
the stream?  Where? I can't find that part.


> You can look at CoreSchema.xod or mvc.hh for the WebRequest API;

Also should be moved out of the core library (at some point).



> 
> Additionally, more or less on a whim, WebRequest provides two different 
> APIs for "page assembly", to help you build a site (as opposed to a 
> webpage): Fragments and Portlets.

What is the purpose of each of these? Why use these indirections? Why 
not just link Vobjects in the normal way? -- the same way as hypervos 
currently does (or perhaps seperate out the children into a group). 
This lookup in Fragments to find other vobjects seems like trying hard 
to do something that VOS is meant to do much more directly...

Same for Portlets... you don't need any special infrastructure to 
implement the general idea of portlets.  If you have a Vobject that 
contains some web content, you just link it in to the page wherever you 
want.

This is what I think the true strength of hypervos is, you don't need to 
work with some restrictive framework like Portlets.  You just link your 
content wherever in the Vobject tree you want.


___
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

[Reed Hedges]

Also what is the rationale behind all the stuff in the IO namespace? 
Is'nt it just a wrapper around standard C++ io?

___
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

[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

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

[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] s5 hypervos (mod_vos)

[Reed Hedges]

Lalo, What are fragments and portlets?



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

[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

[Reed Hedges]

I meant to send a message about this a while ago, but life has 
intervened recently.

Anyway, here are my current thoughts on what to do with Hypervos.

I'm still digesting Lalo's plans, need to reread it or talk to you in 
IRC Lalo.  For one thing, I'm not sure I fully understand the general 
need for explicit MVC classes/objects.  To me, MVC has always been 
implicit in VOS.One set of Vobjects is the Model, the Control is 
implemented by listeners on those Vobjects, which either render the 
'View' directly locally for the user, or manipulate a second set of 
Vobjects to be the View.   You don't need to explictly create some kind 
of "View", it's just there in the second set of Vobjects.   The 
Controllers (listeners) can also be Metaobjects, (so they can be applied 
remotely by users using a UI) and I started doing this in the 
"vostoolbox" library in s4.

Anyway, here's how I was thinking Hypervos could work.

First, is to create a new library to put most of what's currently in the 
vosext_http extension in.  The vosext_http would just be the HTTP 
server, and it would call in to the library to actually render the 
objects.   Other "front ends" could be an Apache module, or simply 
listeners that listen to the entire tree of objects, and write files to 
the disk as things change so another HTTP server can serve static pages 
quickly, or a component of the general UserInterface client to render 
HTML in a pane in the UI.

The hypervos "engine" in the library would then do the work of walking a 
vobject tree assembling them into the output document.  Right now, this 
is just done in a big ugly function in httpserver.cc.  This should be 
changed so that all hypervos and xml object types have actual Metaobject 
components for them.  The "engine" would call "render(request, 
outputstream)" on these Metaobjects, where request is an object 
containing information about the HTTP request.  The base metaobject 
class implementation of render() would be just to return the XML/HTML 
tags to the output stream, write property data, etc. and return.

In the s4 httpserver ("vos" bzr branch) I've added a collection of 
little hacks for special hypervos types that make it easier to represent 
  certain HTML constructs like links and images, and I've also started 
to play with adding things like editing controls, contols to display 
metadata about vobjects, etc.   Right now these are all just added 
ad-hoc to the big ugly rendering function, but these could be seperated 
into Metaobjects/components specific to the special hypervos types.   We 
would do the same thing for templates.  In the future, it will be easy 
to add new "widgets" like this by writing the metaobject/component 
implementations more quickly in Python or another scripting language.

So it would work something like this.

-- HTTPServer front end:
   ostream;

HTTP GET request
   |
   V
   HTTPRequest request (includes info about client, URL, CGI parameters, 
HTTP headers, cookies);
   meta_cast(findObject()) => rootVobject
   rootVobject.render(request, ostream);
   |
   V

-- Hypervos Metaobject Library

Base HypervosObj render(request, ostream):
ostream << startTag << render(children) << endTag;

link widget render(), for example:
ostream << "" + render(linkContents) + 
"";

template render():
...

etc.



Now, this is all pretty web specific.  If you have some objects that 
don't have the XML/web types, you would need to set up listeners that 
can generate XML/Web documents from your other objects, like I described 
above.  However, this process is general to VOS and not specific to 
Hypervos, so we don't need to address it in Hypervos per se.

I also want to implement CGI calls as a way to directly generate VOS 
messages.  This will let us implement all the stuff like forms, 
commenting, online Vobject editing (by mapping the "post" button CGI 
call to a factory message that creates the new post/comment).  Plus I 
have many more ideas.  See http://www.interreality.org/HyperVosIdeas .

Finally, what I'd love to see eventually is a web page that updates in 
real time to changes in VOS (using ajax techniques, and something like 
cometd.)  Doing this requires doing an initial render() as above, but 
then creating listeners that send messages back to the browser as things 
change, and deleting those listeners when the browser session ends.


Reed


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

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

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

[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


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

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


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] Updated "Road Map" on Wiki

[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

[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] Website design ideas

[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

[Reed Hedges]

Karsten Otto wrote:
> Hi Reed,
> 
> Nice work! Regarding the boxes in #1, is there any way to make the  
> round corners anti-aliased? It looks a bit weird in contrast to to  
> the smooth backgroudn image and the anti-aliased VOS logo.

Yeah.  The round corners are a hack using little tiny colored divs. 
Background images look nicer but are harder to make, but that's probably 
what I'd do for the final thing.

> 
> Regarding #2, I think mouseover-popups are not a good idea for large  
> things such as screenshots, better make them popup on click. I like  
> the colorful tree-branch, but maybe that works better as a fixed  
> rather than scrolling background too?

I added a little control at the bottom left to change some of the 
background properties.   One problem is that fixed items seem to really 
slow firefox down. I haven't tried it in IE or Safari yet.

> 
> The only real issue I have is with the headline fonts; maybe it is a  
> Safari/Mac problem, but they look extremely fat, to an extent where  
> they are barely legible.

Hmm.  If you have the "impact" font, that's what they are, if not they 
should just be helvetica.  I think.


___
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

[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

[vos-d] Future of the Blender UI

[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] Website design ideas

[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] Website design ideas

[Reed Hedges]

Here are two ideas I had for a new website design.  Both are rough sketches.

1. http://interreality.org/~reed/tmp/iro/index.html

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


Thoughts, ideas?


Reed


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

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

[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] More new S5 classes/concepts

[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] s5 site ids

[Reed Hedges]

Yeah, I think we should push and see how effectively we can really use 
VOS for and develop tools and practices for that.

For example, if we're working on the UI client and want to put the 
available types in a menu.  You could write a for loop that goes through 
the types and puts each thing in the list.  Or you could write a tool 
that takes any Vobject and lists its children in a menu, and updates the 
menu for changes, etc.   If you can get the tool right, you can reuse 
that in a bunch of other places in the UI.

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

[Reed Hedges]

In VOS it in fact would be easy to build a little tree of the types with 
different names to make them easier for people to work with, while 
keeping their real names hidden.

So you can make an object like "/t" and select out the specific top 
level versions used from the containers ("namespaces"?) with the big ids.

E.g.

/t/vos -> /vos:0011223344556677889900aabbccddee/vos
   ...Has various children for core types...
/t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
   ...Has various children for 3d types...
/t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
   ...Has various children for custom types...

/foo type="/t/mytypes/foo"
/bar type="/t/a3dl/object3d"

Maybe we even enshrine a container like /t or /_types as standard place 
to put the "working set" of types, as a convention that all user 
interfaces use, and so when they are telling a user what the type of a 
vobject is, they can just strip off the prefix, or when preseting the 
user with a list of possible types, just provide a listing (or tree 
view) of the children of /t, etc.

Or a UI can just look at the type definition to get a user friendly type 
name.

But OK, in the general case, we need to come up with ways like this to 
help users navigate vobjects, whether in a particular application or in 
VOS stuff like this, without having to put a lot of special stuff in the 
user interface clients.

Reed





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

Re: [vos-d] s5 site ids

[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

[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

[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

[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

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

[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

[vos-d] More new S5 classes/concepts

[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

[vos-d] VOS on ohloh.net

[Reed Hedges]

For some reason I ended up at ohloh.net so I updated the VOS entry a 
bit. Unfortunately it doesn't support BZR (or tarballs even) so it can't 
do analysis on repository activity or contributors.

http://www.ohloh.net/projects/3930

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] MVC

[Reed Hedges]

Thanks for writing up your thoughts.  How important do you think it is to define
specific interfaces for MVC?

One thing I started doing for S4 was a library called "vos toolbox" that as a
set of tools, mostly in the form of listener classes and metaobject classes,
that can be used to translate events from one group of vobjects into actions
applied to another - i.e. they could be used as building blocks in implementing
MVC controllers.   There are a few checked in to the s4 repository (some that do
math or reformat property values), and I have more ideas listed at
http://interreality.org/wiki/ApplicationVosToolbox

Reed


On Sun, Dec 09, 2007 at 07:07:10PM +, Lalo Martins wrote:
> I posted a draft spec to http://interreality.org/~lalo/mvc.html -- your 
> feedback is appreciated.  I see both Interreality3D and the s5 equivalent 
> of hypervos using this extensively.
> 

___
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

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

[Reed Hedges]

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?

Here's the archive messages about it:
http://thread.gmane.org/gmane.comp.lib.vos.devel/1747/focus=1749 .

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

Anyway, yes please do port it to S5.

Reed


On Fri, Dec 07, 2007 at 06:18:48AM +, Lalo Martins wrote:
> Also spracht Reed Hedges (Thu, 06 Dec 2007 17:46:37 -0500):
> > Or you could use any file format for Vobjects, even COD.   Back in S4 I
> >   sketched out a possible curly-bracket format called "SOD" I think
> > (don't remember it exactly anymore though, maybe there's a message about
> > it in the archive?).
> 
> SOD was a plain-text format which I designed and actually implemented for 
> s4.  I will most likely want to port it to s5 :-) (unless someone wants 
> to do it first)

___
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

[Reed Hedges]

Karsten Otto wrote:
> Am 05.12.2007 um 22:13 schrieb Peter Amstutz:

>>> The interface description seems to slowly approach WSDL Land... Have
>>> you considered some shorthand syntax to free a developer of all the
>>> XML clutter? Or do you envision GUI-based development tools for this
>>> (really the only way to live with WSDL if you have to use it)?
>> I agree.  It's not high on my own list of priorities, but this  
>> would be
>> a good, easy project if someone wants to help out. (hint, hint)
>>
> I am tempted, but probably wouldn't get around to it for a while due  
> to the workload of my current day job. Anybody else? :-)
> 


This is what I was referring to in my other message about setting up a 
clever and elegant XML schema or DTD.  The total schema system would be 
built up and augmented by each new type defined, e.g. by adding XML 
namespaces on top of the base XOD elements or something.

Or you could use any file format for Vobjects, even COD.   Back in S4 I 
  sketched out a possible curly-bracket format called "SOD" I think 
(don't remember it exactly anymore though, maybe there's a message about 
it in the archive?).You can use all the tools for working with 
vobjects in the UI client application to set up the OTD; they can be 
stored remotely; versioned; all the powerful VOS features.

Or we could develop have a super-simple text file whose only purpose is 
to capture the basic OTD information, and have a tool that spits out the 
XOD, and you just put it all together in a Makefile.

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

[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

[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

[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] s5 progress and design

[Reed Hedges]

* Is wrapper locking local or remote?



 > vosIO::CppStdInputStreamWrapper 
inpVobj(factory.create(getLocalHost(),
 >   vosIO::CppStdInputStreamImpl::getClassImplementation()));

Can you explain this a bit more? what is getClassImplementation() and 
why do you pass its result (what kind of object is its result??) to the 
factory?  FactoryWrapper (or whatever implementation it's wrapping) 
seems to be kind of generic?

Also, what's a site replica?


I noticed a few more things that look new:

1. (from XOD text) Format for type strings has changed? Everything is 
prefixed by /OTD?

2. (from XOD text) What's publicId on the ?

3. What's /OTD/vos/Member? What's "owner" mean in the XOD under "Component"?

4. What's /OTD/vos/Lambda?

Maybe you could just annotate your two examples (the code, and the XOD) 
line by line for us?



Superficial comment: If the user is only really interacting with stuff 
via Wrapper classes, why not just chop the name "Wrapper" off the end of 
all those classes? (Or use a shorter suffix.)

Another random comment just looking at the surface -- if we're going to 
be writing XODs to define classes I think XOD needs to be streamlines a 
bit more.   I for one envision getting really sick of writing " Some notes on s5 development progress and design.
> 
> I have made enough progress on developing the s5 kernel that the next 
> milestone (and release) will be to use the "real" s5 VOS in the 
> Interreality 3D prototype.  My intention is to try to keep development 
> grounded by incrementally developing features on the backend and then 
> working to integrate those each feature and improve the frontend.
> 
> The main focus of development for the past couple of months has been on 
> building the code generator which processes an interface description as 
> input and produces C++ classes (interface, implementation, and wrappers) 
> as output.  The generator works on a Vobject structure representing the 
> abstract syntax tree, so the interface description is actually specified 
> using a Vobject XML serialization format.  The first use of the code 
> generator is to specify (and produce) the core VOS classes, which leads 
> to a virtuous cycle where the practical requirements of being able to 
> compile and run the code generator itself drives the first stage of 
> development.
> 
> The general approach of the C++ binding is for each VOS interface to 
> produce a pure virtual interface class, a concrete implementation stub 
> (to be filled in by the developer), and a wrapper class.  The purpose of 
> the wrapper class is to insulate the user from being able to call the 
> implementation object directly, in order to provide a number of 
> features:
> 
>  - Reference counting
>- Provide a standard smart pointer, where the count is decremented 
> when the wrapper goes out of scope.  This will actually be safer than a 
> typical smart pointer, as access to the underlying raw pointer will not 
> be permitted at all.
> 
>  - Locking
>- To avoid locking and unlocking an object with every method call, 
> the wrapper can lock it once, and release the lock when the wrapper goes 
> out of scope.
> 
>  - Soft links
>- The wrapper can refer to an object by path, rather than by pointer, 
> and perform late binding (or in the case of remote objects, no binding 
> at all).
> 
>  - Marshaling
>- If the wrapper refers to an object owned by another thread or 
> process (including remote objects), the wrapper is responsible for 
> marshaling the method parameters a message which is queued for delivery.
> 
>  - Pipelining
>- Because all method calls will be potentially asynchronous, 
> requiring every single call to a method be able to handle a result of 
> "incomplete" would be excessively burdensome.  Piplining allows chaining 
> together multiple calls where each call waits on the "promise" of a 
> pending result.  When the entire chain is resolved (complete, or broken 
> due to an error), the client code is called with the result so that it 
> can continue.
> 
> For the last one (pipelining), I am still mulling over the possibility 
> of using user-level threads instead of (or as an alternative to) 
> requiring the user to save state and unwind the stack manually.
> 
> Also, although all the features above are planned, none of them are 
> implemented, so if you look at the wrappers at the moment, they're just 
> empty shells.
> 
> Here's a couple of samples from the code generator, to get a feeling for 
> what the new API is shaping up like.  First, some code which creates an 
> input stream, and loads a file as a site replica:
> 
> FactoryWrapper factory = getLocalHost().getFactory();
> 
> std::ifstream inp(inputFile);
> vosIO::CppStdInputStreamWrapper inpVobj(factory.create(getLocalHost(),
>   vosIO::CppStdInputStreamImpl::getClassImplementation()));
> inpVobj.setStdStream(&inp);
> SiteWrapper root = importReplica(inpVobj);
> 
> Next, some

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

[Reed Hedges]

Well, we don't want to take on all the baggage that other "Component systems"
have.

But then again, we're just talking about naming a class here, not the whole
system.

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

[Reed Hedges]

On Thu, Nov 29, 2007 at 11:16:16AM -0500, Peter Amstutz wrote:
> "Part" is even more generic/vague than component

True, but it's not used very often in software (IME at least).

Component does imply that it could be provided by a plugin module, and
is dynamic, both of which are attributes of MetaObjects.


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

[Reed Hedges]

I guess it's a Decorator pattern, which other people might be familiar with 
from the
Design Patterns books, so could be named after that.  Though it's an unfortunate
name, calling MetaObjects "Decorations" would kind of trivialize them :)   I
wonder where they came up with that name.

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

[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] thinking about a new web site

[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

[vos-d] S5 and ordering listeners

[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] notes from IRC

[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] notes from IRC

[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

[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

[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] Forums integrated with mailing lists

[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

[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

[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

[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

[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] issue building on OS X

[Reed Hedges]

Hi Jake, I just removed that from Makefile.am. Update from bzr and try again.

What version of automake do you have?

Reed


On Wed, Aug 29, 2007 at 09:34:24PM -0600, Jake Franklin wrote:
> Hi,
> 
> I'm attempting to use the vos-bootstrap script to build VOS.  I've
> installed already installed bazaar-ng and the XCode packages.
> 
> The build seems to die early on though:
> 
> $ ./vos-bootstrap.sh bzr
> Creating or updating vos bzr branch from 
> http://interreality.org/home/bzroot/vos
> Branched 1133 revision(s).
> configure.ac: installing `./install-sh'
> configure.ac: installing `./mkinstalldirs'
> configure.ac: installing `./missing'
> apps/a3dldemo/Makefile.am: installing `./depcomp'
> apps/omnivos/Makefile.am:15: invalid variable `dist_doc_DATA'
> apps/omnivos/Makefile.am:15: invalid variable `dist_doc_DATA'
> autoreconf: automake failed with exit status: 1
> 
> Any suggestions?  I've searched the lists and didn't see anything similar.
> 
> Thanks!
> 
> --Jake
> 
> ___
> 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] development plan

[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

[vos-d] Interpolation in TerAngreal

[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] What do we want in the 0.24 release?

[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

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

[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!)

[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!)

[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

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

[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

Re: [vos-d] thoughts and plans

[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] thoughts and plans

[Reed Hedges]

I think we do need modes for keybindings, and I like the general tool idea.  
The GUI should not neccesarily be directly mapped to mode.n ia fixed 
configuration though.  Instead, there should be a set of GUI elements (side 
panes, etc.) for each mode, but they should be flexible in that you can bring 
up other GUI elements, minimize elements, and it should remember that layout 
configuration for the next time you enter that mode.  And, mode transitions 
should be tools/bound actions. For example, you define in configuration that 
middle mouse click means to "select" an object, and also enter editing mode 
with that object selected.  By entering edit mode, the GUI layout for that 
mode would be displayed, which might include window panes with different 
toolboxes or information about the object displayed. But maybe you want some 
panes to always be visible in all modes, etc.; maybe you want to hide the chat 
pane while you're in edit mode or minimize it so that there's a little button 
on the edge of the screen that brings it back, etc.

I think tool panes/sidebars that you optionally float and move or iconify are a 
useful way to present buttons, tools, and object trees that makes them easily
accessible and viewable.

(We should also definately adopt Firefox's method of displaying background
notifications and non-modal dialog boxes by inserting them above or below the
main viewing area rather than as popups :)

Reed


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

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

[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

[vos-d] tags, trees, tables, and types

[Reed Hedges]

On Wed, Jun 27, 2007 at 10:38:37AM -0400, Andrew Robbins wrote:
> I have also been thinking a great deal 
> about tables, tags, trees, and types (talk about illiteration!). The 
> reason I've been thinking so much about them is that every once in 
> awhile, I'll come up with a new way of converting between one or the 
> other. For example, unlike flickr.com tags, if there was a primary tag 
> and a secondary list of tags (and you could tag tags with tags), then 
> this kind of tag-based system would be isomorphic to a tree-based system 
> (like directory structure) represented as a folder (representing the 
> primary tag) containing the item, with symlinks to this item in other 
> folders (representing the secondary tags). The only problem with this 
> isomorphism is that tag-based systems usually have an implicit global 
> namespace.

I've also been thinking about tags and metadata, namely in conjunction with
hypervos and web stuff.

Currently, the "misc:metadata" type has a property called "keywords".  What I'd
like to do is change that to a group of vobjects representing each keyword
(a/k/a tag), such that vobject that share a tag actually each have a link
(pointer) to the same tag vobject, rather than just having a copy of the keyword
text in each vobjects keywords property.   From there, you could go in all kinds
of directions for analyzing tags/keywords, or organizing them into groups,
connecting "synonym" keywords to each other, etc.

Haven't implemented this but will someday.

A conceptual goal for VOS is to use and re-use the core Vobject concepts as much
as possible to form different structures that overlap or share the same data,
and to be able to apply general tools to different sets of data.


> Back to tables, tags, trees, and types. I honestly think that if the 
> right metadata were available for a given dataset, you should be able to 
> convert between these representations automatically, so much so that it 
> should be a UI option when viewing a given dataset. I have already 
> described an isomorphism between tags <=> trees (assuming a set of 
> unique identifiers, and a primary tag), and I would like to remind of a 
> common situation for converting between tables <=> trees, for example 
...

This is interesting.  And it could be done, I think, for any vobject tree.

One of the todo items for terangreal
(http://interreality.org/wiki/UserInterface) is to incorporate a generic Vobject
Editor GUI, which would also be avaliable as a stand alone app
(http://interreality.org/wiki/VobjectEditingGui).  This editor should have
different view styles available that you could switch between. These views could
be just a list, a standard collapsable tree GUI, a zoomable visual graph (nodes
and edges), etc.  A table like that could be one of them too.


Reed



___
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!)

[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

[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

[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

[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

Re: [vos-d] Errors building crystalspace

[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] Errors building crystalspace

[Reed Hedges]

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?




C++ ./out/linuxx86/debug/libs/csutil/csstring.o
./include/csutil/formatter.h:992: error: non-template 
'IEEEFloatMantissa' used as template
./include/csutil/formatter.h:992: note: use 'csPrintfFormatter::template IEEEFloatMantissa' to indicate that it is a template
./include/csutil/formatter.h: In constructor 'csPrintfFormatter::IEEEFloatSplitter::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 
'csPrintfFormatter 
 >::IEEEFloatSplitter':
./include/csutil/formatter.h:1043:   instantiated from 'void 
csPrintfFormatter::OutputFloatHex(Twriter&, const 
csPrintfFormatter::FormatSpec&, const T&, int, int, 
int) [with T = long double, Twriter = csStringFmtWriter, Treader = 
csFmtDefaultReader]'
./include/csutil/formatter.h:1407:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:992: error: type 
'csPrintfFormatter 
 >' is not a base type for type 'csPrintfFormatter >::IEEEFloatSplitter'
./include/csutil/formatter.h: In member function 'void 
csPrintfFormatter::OutputFloatHex(Twriter&, const 
csPrintfFormatter::FormatSpec&, const T&, int, int, 
int) [with T = long double, Twriter = csStringFmtWriter, Treader = 
csFmtDefaultReader]':
./include/csutil/formatter.h:1407:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1046: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1067: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1108: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1110: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1112: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1407:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1116: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h:1407:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1136: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 
'mantissa'
./include/csutil/formatter.h: At global scope:
./include/csutil/formatter.h: In instantiation of 
'csPrintfFormatter 
 >::IEEEFloatSplitter':
./include/csutil/formatter.h:1043:   instantiated from 'void 
csPrintfFormatter::OutputFloatHex(Twriter&, const 
csPrintfFormatter::FormatSpec&, const T&, int, int, 
int) [with T = double, Twriter = csStringFmtWriter, Treader = 
csFmtDefaultReader]'
./include/csutil/formatter.h:1411:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:992: error: type 
'csPrintfFormatter 
 >' is not a base type for type 'csPrintfFormatter >::IEEEFloatSplitter'
./include/csutil/formatter.h: In member function 'void 
csPrintfFormatter::OutputFloatHex(Twriter&, const 
csPrintfFormatter::FormatSpec&, const T&, int, int, 
int) [with T = double, Twriter = csStringFmtWriter, Treader = 
csFmtDefaultReader]':
./include/csutil/formatter.h:1411:   instantiated from 'void 
csPrintfFormatter::Format(Twriter&) [with Twriter = 
csStringFmtWriter, Treader = csFmtDefaultReader]'
libs/csutil/csstring.cpp:117:   instantiated from here
./include/csutil/formatter.h:1046: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 'mantissa'
./include/csutil/formatter.h:1067: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 'mantissa'
./include/csutil/formatter.h:1108: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 'mantissa'
./include/csutil/formatter.h:1110: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSplitter' has no member named 'mantissa'
./include/csutil/formatter.h:1112: error: 'struct 
csPrintfFormatter 
 >::IEEEFloatSpli

Re: [vos-d] A3dl redesign (was Re: Scaling and Origins -- 0.23 vs0.24)

[Reed Hedges]

On Tue, May 22, 2007 at 09:03:29AM -0700, Ken Taylor wrote:
> I guess my suggestion really comes down to, when in doubt, follow X3D,
> because they're putting a lot of work into making this stuff flexible and
> interoperable :)

Well, not neccesarily. I mean in the data design.  Legacy VRML support
tends to be a bit more important.

But in general I agree with you about considering interop over ease of
implementation in CrystalSpace.

> As for ease of use, you want to support editing in-world, but I wouldn't
> have a problem letting the client do most of the work translating the easy
> editing interface to actual a3dl representation. 


Well, I sort of disagree, in a sense.  One thing I want to see as we develop VOS
tools is to expose all of the VOS concepts and structures directly to
the user.  (Then add helper tools on top, as needed.)   I think this
will result in a much more powerful and also consistent and easy to
understant user experience.

> Some people will want to be able to make lush,
> interesting worlds with lots of advanced content, and others will want to
> make things quickly and in real-time with primitives, and VOS should be able
> to make both groups happy. 

Yes, exactly. And in fact th best way to support the lush graphics is to 
support import from tools like Maya and Blender that are well suited to that.   
But to support the primitives, and also tweaking of the lush and adding
behaviors and application data is to also have an A3DL object model
that's easy for the user to access directly, without going through other
tools, if he needs to.

Reed

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

Re: [vos-d] A3dl redesign (was Re: Scaling and Origins -- 0.23 vs 0.24)

[Reed Hedges]

In making A3DL we did take some inspiration from VRML.  However, VRML
(and X3D) have some aspects that if adopted directly would make A3DL
a bit less efficient or more cumbersome.  We have all the structure that
comes from VOS to use.  X3D does some stuff just because VRML did it,
and VRML97 does it because VRML 1.0 did it, and VRML 1.0 did it because
Inventor did it, and SGI GL,  etc. etc.  

We should do what is closest to overall common practice. i.e. if VRML,
CrystalSpace, other 3D engines, Collada, etc. all do somtehing in a very
similar way, we should probably do that.   In some cases we will have to
break with X3D (or other existing stuff) though and do it better (better
for VOS).

The two overarching design goals for A3DL are to first, make it work
efficiently and be flexible and useful to manipulate A3DL objects in and
of itself.   Second, to make it easy to import existing content.  These
two things will be in conflict sometimes.  I don't know which should be
primary, but I lean towards making A3DL itself easy to use (e.g. imagine
you're interactively editing A3DL objects with a GUI version of mesh)
and very flexible (e.g. imagine that you want to share content between a
3D and a 2D application, or between 3D worlds, you want to make something 
clever and neat in A3DL.)

(Also, in the "designing metaobject structures" vein, there's a Wiki
page about "Tips and Best Practices" here:
http://interreality.org/wiki/TipsAndBestPractices . I started it out
with a few tips and TODO items, add more TODOs (and tips) as you
encounter situations and figure things out.)



Reed

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

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

[Reed Hedges]

Reed Hedges wrote:
> 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

I mean both object name and contextual name.

___
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

[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

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

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

[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=-6972678839686672840&hl=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] delineation and revision control

[Reed Hedges]

Yes, only some things would be versioned, or have different policies as
Lalo suggests.

Yes, child linking has to be preserved correctly. I think we can
basically take an object's child list as part of its state. When you
make a new version you might change those, or copy them whole from the
original.  In your example, the texture belongs to both I guess, but
really, both objects have links/references to some objects, that it 
just happens to be the same one can be looked over for the most part I
think.

Reed



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

___
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"

[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