Interoperability-themed Croquet technical conference call -friday November 30- at 2:30 EDT = 1:30 CDT = 11:30 PDT

The Croquet technical meeting/conference call tomorrow (Friday,  
November 30)
at 2:30 EDT = 1:30 CDT = 11:30 PDT has an interoperability theme.

After a number of informal discussions, it seem that there are 6 main  
areas to
concentrate on. We will discuss these to make sure we are not missing  
anything
crucially important, then try to sort out who is going to shepherd  
each of these
areas.

We will be meeting using a QWAQ forums space, which means you need
an account to participate - e-mail me if you need an account.

----------------------------------------------------
                    draft agenda
----------------------------------------------------

1.) Development Roadmap - the top 6 items we need to work on for  
interoperability:

- XML space description: a common space description file format in  
XML to allow the open source and QWAQ clients to read stored copies  
of each other's worlds.

Minimizing the size of objects being replicated is important so that  
spaces may be saved compactly and new user joining the replicated  
space can do so quickly.

In practice this means meshes and textures should be referred to by  
name in the replicated space, and fetched by each client  
independently of joining the space. By fetching these large objects  
independently of the replicated space, clients can maintain locally  
cached copies which speeds joining the space. An XML description of  
the space also simplifies programatically generating space  
descriptions, and aids in integration with various search engine  
technologies.

Moreover, an XML-based space description also allows for the  
possibility of a croquet browser written in another language or based  
on a different code base. However, this implies changes to the  
rendering engine since we would be moving textures/mesh definitions  
outside the replicated space. QWAQ's forums have shown that this  
approach has many virtues. Ultimately we might want to use an  
extended version of Collada - but the first step would be to align  
the Open source and QWAQ code bases so we can read each other's world  
definitions.


- robust Jabber client: SSL TLS support ( OpenSSL plugin?)

This work can happen in the open source arena and is relatively  
independent of changes to space description formats. The current  
Jabber client does not support SSL transport level security and needs  
to - since most Jabber servers require SSL TLS. Supporting an open  
standard IM/Chat is a key for interoperability with the chat world,  
and ideally would allow cross world chat with other environments  
(such as Second Life) should those worlds decide to do the right  
thing and support a standards based chat protocol for inter world  
chatting. We also need this work so that we can advertise presence  
outside Croquet using an open standards-base approach


- message router/timestamper: optional message router/timestamper as  
an Apache plugin?

The microserver is a message router/timestamper for sites that want a  
standalone message router to augment the croquet client built-in  
router. We can leverage the support that the apache server codebase  
has by providing an option to externalize the message router function.

This also opens the possibility of simplifying access control/
authentication integration with existing enterprise AuthN/AuthZ  
systems. By creating a microserver that plays in the apache space we  
can leverage existing Apache web server authentication/access control  
modules.



- plugin API for extending space definitions: various browsers will  
extend functionality of spaces by adding new features, we need a  
definition for how this happens

We expect that various browsers will extend functionality of spaces  
by adding new features. We need a standard way to describe these  
plugins that allows less well endowed clients to at least display a  
placeholder for content they cannot render and point to how to get  
the required extension. This is analogous to plugins for web pages.

Note that these plugins may affect both the replicated space -and-  
the non-replicated inside-the-helmet user interface of a croquet client.


- scripting for user-defined behaviors: Javascript, Lua, panels, roll-
your-own, and all that jazz

If we have a common XML format for describing spaces we have half of  
what we need. The other half is a common way of describing user-
created behaviors, so a scripting language - like lua or javascript -  
would allow for actions to be stored along with models and textures.  
This implies that browsers will all need to support the scripting  
language.


- avatar definitions: enabling Akbar 'n Jef's Avatar Hut

Users of social spaces care a lot about their representation in-world  
- we need to converge on avatar standards so that each implementation  
of croquet is not re-inventing this particular wheel. That, and a  
good babyfur avatar should be a lifetime investment.


2.) Who is going to take responsibility for which items in the  
Development Roadmap?



Mark P. McCahill
Architect, Computing Systems
Duke University - Office of Information Technology
334 Blackwell Street, Suite 2107
Durham, North Carolina 27701
USA

[hidden email]
+1 919-724-0708  (mobile)
+1 929 668 2964  (fax)

Mark,

Have the account you gave me. Now I need details about downloading the client and how to connect to the QWAQ forum. I have played with croquet a bit, but its been a while. Mostly do SL and AW lately. Thanks

----- Original Message ----
From: Mark P. McCahill <[hidden email]>
To: [hidden email]
Sent: Thursday, November 29, 2007 10:08:32 PM
Subject: [croquet-dev] Interoperability-themed Croquet technical conference call  -friday November 30- at 2:30 EDT = 1:30 CDT = 11:30 PDT  


The Croquet technical meeting/conference call tomorrow (Friday,  
November 30)
at 2:30 EDT = 1:30 CDT = 11:30 PDT has an interoperability theme.

After a number of informal discussions, it seem that there are 6 main  
areas to
concentrate on. We will discuss these to make sure we are not missing  
anything
crucially important, then try to sort out who is going to shepherd  
each of these
areas.

We will be meeting using a QWAQ forums space, which means you need
an account to participate - e-mail me if you need an account.

----------------------------------------------------
                    draft agenda
----------------------------------------------------

1.) Development Roadmap - the top 6 items we need to work on for  
interoperability:

- XML space description: a common space description file format in  
XML to allow the open source and QWAQ clients to read stored copies  
of each other's worlds.

Minimizing the size of objects being replicated is important so that  
spaces may be saved compactly and new user joining the replicated  
space can do so quickly.

In practice this means meshes and textures should be referred to by  
name in the replicated space, and fetched by each client  
independently of joining the space. By fetching these large objects  
independently of the replicated space, clients can maintain locally  
cached copies which speeds joining the space. An XML description of  
the space also simplifies programatically generating space  
descriptions, and aids in integration with various search engine  
technologies.

Moreover, an XML-based space description also allows for the  
possibility of a croquet browser written in another language or based  
on a different code base. However, this implies changes to the  
rendering engine since we would be moving textures/mesh definitions  
outside the replicated space. QWAQ's forums have shown that this  
approach has many virtues. Ultimately we might want to use an  
extended version of Collada - but the first step would be to align  
the Open source and QWAQ code bases so we can read each other's world  
definitions.


- robust Jabber client: SSL TLS support ( OpenSSL plugin?)

This work can happen in the open source arena and is relatively  
independent of changes to space description formats. The current  
Jabber client does not support SSL transport level security and needs  
to - since most Jabber servers require SSL TLS. Supporting an open  
standard IM/Chat is a key for interoperability with the chat world,  
and ideally would allow cross world chat with other environments  
(such as Second Life) should those worlds decide to do the right  
thing and support a standards based chat protocol for inter world  
chatting. We also need this work so that we can advertise presence  
outside Croquet using an open standards-base approach


- message router/timestamper: optional message router/timestamper as  
an Apache plugin?

The microserver is a message router/timestamper for sites that want a  
standalone message router to augment the croquet client built-in  
router. We can leverage the support that the apache server codebase  
has by providing an option to externalize the message router function.

This also opens the possibility of simplifying access control/
authentication integration with existing enterprise AuthN/AuthZ  
systems. By creating a microserver that plays in the apache space we  
can leverage existing Apache web server authentication/access control  
modules.



- plugin API for extending space definitions: various browsers will  
extend functionality of spaces by adding new features, we need a  
definition for how this happens

We expect that various browsers will extend functionality of spaces  
by adding new features. We need a standard way to describe these  
plugins that allows less well endowed clients to at least display a  
placeholder for content they cannot render and point to how to get  
the required extension. This is analogous to plugins for web pages.

Note that these plugins may affect both the replicated space -and-  
the non-replicated inside-the-helmet user interface of a croquet
 client.


- scripting for user-defined behaviors: Javascript, Lua, panels, roll-
your-own, and all that jazz

If we have a common XML format for describing spaces we have half of  
what we need. The other half is a common way of describing user-
created behaviors, so a scripting language - like lua or javascript -  
would allow for actions to be stored along with models and textures.  
This implies that browsers will all need to support the scripting  
language.


- avatar definitions: enabling Akbar 'n Jef's Avatar Hut

Users of social spaces care a lot about their representation in-world  
- we need to converge on avatar standards so that each implementation  
of croquet is not re-inventing this particular wheel. That, and a  
good babyfur avatar should be a lifetime investment.


2.) Who is going to take responsibility for which items in the  
Development Roadmap?



Mark P. McCahill
Architect, Computing Systems
Duke University - Office of Information Technology
334 Blackwell Street, Suite 2107
Durham, North Carolina 27701
USA

[hidden email]
+1 919-724-0708  (mobile)
+1 929 668 2964  (fax)







      ____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 

Hello there,

I just logged in to Mark's technical conference. I'm
an extreme newbie and was pleased to see the
possibilities beyond my experience with Second Life.

Everyone was very kind and I saw some quite
interesting computer-supported collaboration.

Is this project Open Source or closed commercial? As a
potential participant, I'm a tad hesitant to throw
effort into a project that seems mostly proprietary?
Obviously I don't know the players at all but aren't
the more usable portions pay for play?

Just trying to understand how the open source portion
of the project is able to thrive in the shadow of a
commercial fork? Or maybe this is a case where the
TRUE project has transitioned to paid and the left
overs continues on lightly supported? I guess this
makes the part I can participate in a "spoon?"

--j


- Jeremy Kemp, M.Ed., M.S.J.
Assistant Director, SL Campus
SJSU School of Library & Information Science
(408) 393-5270 Cell, (408) 924-2466 Office
"SJSU SLIS" on the SL map
SL Avatar: Jeremy Kabumpo

Join SLED Builders!
http://lists.simteach.com/listinfo.cgi/sledbuilders-simteach.com

Jeremy,

The project is very much open source. Qwaq is a major contributor to it,
and has been since we started the company and before that when we
started the Croquet Project. We went dark for a bit as we were focused
on building a new business but I think we have enough breathing room now
to push ahead. Qwaq Forums is indeed pay-to-play, but I think it
represents how Croquet will be evolving over the next year or so. Our
goal is to ensure that Qwaq Forums and Open Croquet worlds are
interoperable. This will require Qwaq to provide much of the effort and
technical leadership for this next push and we are doing just that. The
issues that were raised at the meeting are real - and are critical for
everyone's success.

Regards,

David




Jeremy Kemp wrote:

Hello,

(Again emphasizing my humble newbie-ness)

So you mean that this project is driven by Qwaq
Forums? You are setting the agenda and roadmap. New
initiatives come from paid developers writing
proprietary code? Then new stuff is opened about a
year after being offered for sale?

--J

--- David A Smith <[hidden email]> wrote:
http://lists.simteach.com/listinfo.cgi/sledbuilders-simteach.com
> >
> >  
>
>

On Nov 30, 2007, at 4:36 PM, Jeremy Kemp wrote:

Qwaq are certainly major players here - but the general open source
community and several Universities have made major contributions as  
well.

For instance - the spatialized audio (OpenAL) support was first
developed at the University of Minnesota back when I was leading the
Croquet team there. That happened after a similar roadmap/priority
setting exercise to what you saw today, when I signed the U of M team
up for doing audio. In-world text and audio annotations are another
outgrowth of that work as is in-world record/playback for NPCs and
machinima sorts of applications.

I've moved from Minnesota to Duke, but Liz Wendland and
Peter Moore continue to make major contributions at Minnesota.
Recently a lot of work has gone into animated avatars. For an example
of the sorts of things the universities have been doing, see the
video here: http://croquet.umn.edu/movies/bigCroquelandia.mov

When Josh Gargus, Howard Sterns and Julian Lombardi were at UW-Madison
a lot of work work happened there, and it all went directly
into the open source code base. Josh and Howard recently joined Qwaq
and Julian is here at Duke where the Croquet Consortium is based.
The Consortium's role is to promote interoperability and the open source
community, so we work with both the non-profit and commercial worlds
toward this end.

My current interest is in getting a pure open-source browser/interlinked
world application out and maintaining interoperability with whatever
commercial applications use the technology.

So... Croquet is really open source and the community spans Qwaq,
universities, and individuals.


Mark P. McCahill
Architect, Computing Systems
Duke University - Office of Information Technology
334 Blackwell Street, Suite 2107
Durham, North Carolina 27701
USA

[hidden email]
+1 919-724-0708  (mobile)
+1 929 668 2964  (fax)

Hello David,

if Qwaq to Croquet interoperability is an issue:  how much is Qwaq an  
Croquet like the open source for everyone to have Croquet ? I assume  
(by your post, Blog and press news from Qwaq) that Qwaq has now an  
much more advanced version of Croquet. What technical differences -  
if any - are there between the two incarnations of Croquet ? For  
example both use the same Squeak version in it (or not) etc etc....

Regards


Hans

Am 30.11.2007 um 22:26 schrieb David A Smith:

There are a variety of actions and concurrent activities going on here,
but let me state the following, which will remain true, even in states
of transition.

Croquet (like Linux) is trademarked, as well as a body of code.  For
Croquet in particular, there may be variations over time in the source
code, in the release state of specific versions, etc.   However,
Croquet, the trademark, may only be used in conjunction with code that
meets the Croquet founders' collective approval.  The founders are me,
David Smith, Andreas Raab, and Alan Kay.

It has been, and still is, our intention to use control of the trademark
to ensure interoperability of various versions of Croquet.  (just as
Linus Torvalds controls the Linux trademark and its use, though various
instantiations and variants of Linux exist).

Qwaq Forums and the public version of Croquet that non-Qwaq developers
use meet this criterion.

If someone exploits the license (essentially a so-called MIT license,
rather than a GPL-style license or other open source license) to create
a "fork", it would be wise to consult with the founders as to whether
the Croquet trademark can be used.

The "Squeak" component of Croquet is not strictly a part of Croquet.

Those who have some knowledge of the open source licensing world (which
is arcane, and probably not something that is helped by debate among the
less informed) will realize that because the Croquet license is NOT a
GPL-style license, the notion of a "distribution" is not particularly
relevant, as it is in the case of Linux.  In GPL, the "distribution" has
a legal impact that is quite significant on what one can and cannot do.  
In MIT-style licenses, there is less of a concern.

We made this licensing-style choice and dependence on trademark, if you
are interested, because Croquet is a distributed system defined by
interfaces, not by copyrighted code - the correct workings of Croquet
relate to whether it "connects" with other instances, rather than what
is precisely contained in any particular machine's body of source code
or image.  Subsets of the code may be all that is needed for specialized
nodes, ...  and some nodes may require tight integration with packages
of diverse heritage, proprietary code, etc. to be useful - and are not
released by DVD images or other "compiled" or early-bound packaging
technologies.

For systems like Croquet, which are behavior defined, rather than
source-code body defined such as GCC or Linux kernel, the issue of
managing a community of developers are somewhat different.

Let me note here that while I am not currently writing code for Croquet,
I personally, as one of the founders, am still actively involved and
committed to the community.  (and I continue to research concepts that
may be used in future development, or not).

Hans N Beck wrote:

There are a number of differences between the Hedghog source and where
Qwaq is now, but the fundamentals are the same. Bear in mind that the
Hedghog release was Qwaq's Croquet version when we released it as well.
This time, we have a lot of proprietary code (third party and our own)
that we can't (or won't) release, but the key Croquet technologies will
be released. Just to start, we have worked hard to make sure the low
level Homebase Squeak code remains up to date with our fixes. We simply
have not had time for much else. We were hoping for some funding to help
with both the release of a Croquet browser (that we would no doubt build
the majority of) and to help develop some of the essential new code, but
this funding has not yet appeared so we have to do everything on our own
dime and in our own time.

David Reed is correct that the definition of Croquet is that it
interoperate with the "blessed" version, which happens to be Hedgehog at
the moment. Jabberwocky is to be the new "blessed" code base, and will
define Croquet interoperability. There are a number of levels to that -
interoperability of world definitions, interoperability between clients,
and interoperability between versions. Our roadmap directly addresses
the first level: interoperability of worlds. The second is realizable,
but difficult simply because of the versioning problem. This last is
proving to be a bit complex, but is essential to achieving what David
described. We think we have a way to make this work as well, though it
is a theoretical argument at the moment. A key element to this is
providing the replicated scripting language which will make the need for
versioning significantly less of an issue than it is now.
 
Our goal is to move forward quickly on the six item road map that Mark
and I put together. Of the six, we have two of them working internally
at Qwaq - XML persistence and 2D plug-ins, and we will be making them
available. The Jabber technology exists, but is still quite primitive.
There is no Apache plug in, there is no in-Island scripting language
available, and we do not have a hardened avatar capability yet, though
Minnesota has been doing a great job in moving that forward. Please let
us know what other priorities might exist that we may have overlooked,
but I think this makes for a pretty compelling system.

David


Hans N Beck wrote:

Hi David A Smith, David P Reed,

thank you very much for the explanations !  It is interesting that  
you keep your concept potentially open for Croquet Browsers build  
with other systems or languages. And it is also good to hear that  -  
although Qwaq as a company has all right to go on as they need to  
have success - that the intention is to keep the contact in  
functional and conceptual aspects with the Open Source Croquet. So I  
am very interested to see how this all goes on, and also my interest  
is growing again on Croquet to work with for own experiments  
(relatetd to applications).

Best Regards

Hans




Am 01.12.2007 um 17:17 schrieb David A Smith: