Nabble - Croquet - Dev 2

Re: using croquet as an interaction platform for issue tracking ???

2007-01-11T17:21:08Z

Interesting project! I'll base my comments (inline, below) on what
is in the public code repository -- available now to developers
(http://hedgehog.software.umn.edu:8888/), and undergoing testing for
inclusion in a pre-loaded image for the next distribution.

These are my opinions. I don't speak for anyone (regardless of
signature).

On Jan 10, 2007, at 3:35 AM, Hussayn Dabbous wrote:

> Hi, all;
>
> I am brand new to VR in general and to Croquet in special, although
> i am a programmer
> having about 30 years of experience with all sorts of software
> development starting with
> microcomputer programming in the midth of the 70's and ending up
> running a small software
> development company specialised on webapplication technology.
> So recently i took a brief look into some VR technologies,
> especially second life has
> attracted me in first place which IMHO is very impressive namely
> its look and feel. That's
> nice for leisure, but i am not quite convinced regarding second
> life as a platform for
> serious working in the first world ;-).
>
> So i turned to Croquet and found its key technology much more
> interesting especially
> because i am interested in a concrete scenario, where i want to
> make the interaction
> between our software development and our customers more efficient.
> And i believe, Croquet
> could do something for us here in a much better way than other
> solutions can do. But as
> a newbie in this field i am unsure whether i am really going the
> right way. Hence i took
> some time to bring my beginner's ideas to this email hoping to get
> some brief answers.
>
> So here we go: I think about a virtual issue tracking system
> involving direct virtual
> interaction between customer and developers. I'd like to verify
> whether the following
> use case can already be implemented with todays Croquet
> implementation:
>
> The use case
> ============
>
> We are currently using a web based issue tracking system (namely
> Scarab, maybe you have
> heard about it ?) for communication between our development and our
> customers. Very often
> text based issues are not expressive enough to understand the
> problem. Hence we need to
> get to the phone and let us explain in lengthy words what the
> customer problems are all
> about. Often we need to place ourselves in front of the Browser and
> try to reproduce
> described effects on the customer system. We have a connection via
> VPN and thus can get
> into the customers computer system for maintenance purpose. This
> scenario has prooven
> efficient regarding to the main stream tools as available today
> (browser, webapplications,
> telecomunications, vpn, ...), but i like to push this (much) further:
>
> 1.) I want to create two virtual worlds, i.e. two rooms in Croquet:
>
> - development lab where a customer can take a look into our
> ongoing work, e.g.
> play around with our development system (a webapplication).
> This playing may be
> acompanied by a developer, who shall comunicate how to use
> the frontend by
> using his developer avatar, while the customer avatar may
> listen e.g. via voip
> The customer may also utilise our testsystem either directly
> from the web, or
> through a viewport from Croquet.
> The development lab shall physically run on one of our
> company servers.
>
> - customer lab where a customer offers a direct view to his
> production and
> test systems. The main functionalities are technically more
> or less equivalent
> to what we want to offer in the development lab above.
> The devleopment lab shall run on one of the customers
> computers.
>
> 2.) The development lab and the customer lab shall be connected via
> a portal, thus
> customers and developers can enter both rooms whenever needed
> and start a comunication
> with others when online.
>
> 3.) a user (developer or customer) can leave a message to another
> user at any place. This
> message shall be physically organised in our issue tracking
> system, which is also web based
> and allows to enter issue related comments, upload/download
> any files.
>
> 4.) through the customer lab we shall get direct access to e.g. a
> terminal window from where
> we can start a terminal session either directly in Croquet or
> on an external window which
> runs a terminal software (e.g. putty)
>
> Some questions
> ==============
>
> The above scenario is just a rough sketch about what i have
> currently in mind. One of the
> crucial points is about acceptance of such a system. So here are my
> essential questions:
>
> 0.) Does it make sense in first place ?

Yes. The complete scenario could be prototyped entirely in the "KAT
demo" in the Software Developer's Kit, from within the system as you
are using it, without any programming at all. A closed, proprietary,
specialized, branded, and tuned application could then be built using
the SDK, and delivered as you see fit.

>
> 1.) Is it possible to create a custom croquet containing our own
> avatars instead of the
> original ones coming with the Croquet sdk ?

Yes. Even as they exist now, several of the demos, including the KAT,
provide the ability to change avatars.

+ Some of the demos (including KAT), provide the ability to load
arbitrary .ase format models (programatically or interactively).
+ There is code in the repository (that I have not used myself), that
also loads arbitrary .vrml format models.
+ Previous internal versions of what has become the KAT demo allowed
you to interactively select anything in the world any "wear" it as
your avatar.
and...
- Two of the demos, Sailing and Simple Demo, allow you to
interactively load an articulated Poser avatar such as those used in
Second Life, and assign specific motions to it for walking, standing,
typing, etc.

> Can we also remove the demo worlds and
> just keep a template for the customer-room? Such that we can
> let our customer
> download the Croquet viewer, start it and get right to where
> we want him to go
> without learning anything about croquet, just jumping in and
> start with the intended
> application ?

Yes. You can program your application to connect to any world you like.

The "Croquet viewer" as you call it, is actually a complete and quite
malleable development and delivery environment called Squeak. You can
interactively define whatever applications, buttons, controls,
instructions, etc. that you like, save it, and ship the result.

I think it is instructive to see how you could interactively create a
complete concept-to-delivery prototype for your scenario. Using the
SDK (either the pending version or the currently available one after
updating by you from the repository),

1. Start the KAT demo. When prompted for a place to connect to, do
not connect to any public commons (which is not available yet, prior
to the release). Instead, just enter a blank address. The demo will
just run locally on your machine.

2. The world your machine will build is mostly empty except for some
portals. Most of these are to empty worlds. One is the standard demo
world. Delete the portals you don't want. Interactively add and
arrange the stuff you do want.

3. Cache the current version of all the worlds onto your disk, using
the 'Admin' menu.

4. Distribute your version of the SKD. You do not need to distribute
the cache.

5. To run in "production," start your copy as in steps 1 and 2. It
will load your worlds from your cache. Leave that machine running.

6. Tell everyone else to start as in 1, but for step 2, give them the
address of the machine you use in step 5.

There are engineering issues, of course, but these are the essentials.

>
> 2.) Is it possible to efficiently connect Croquet viewing portals
> with a Webapplication
> running in the same domain as Croquet runs in ?

I'm getting this question confused with 3 and 7, below. Can you clarify?

>
> 3.) Is it possible to connect a Croquet Viewing portal with a
> terminal program, i.e. putty ?

Yes.

The core technology for this is a class called TEmbeddedApp. There
are several examples in the SDK of how you can program various kinds
of embedded applications. The KAT demo let's you interactively create
two kinds:

+ A simple text panel from the underlying Squeak environment. What's
really happening is that each Croquet participant receives the same
input (mouse and keyboard) for the text panel, which is passed on to
a 2D Squeak text window "outside" of Croquet, and the result
displayed within Croquet. The Croquet code built on top of
TEmbeddedApp manages the state of the text panel within Croquet, so
that anyone joining late can get the correct state for their local
Squeak.

+ A full Virtual Network Computing (VNC) client viewer, connecting to
an external server. The VNC client is also built in 2D Squeak, but
maintains its own separate TCP Socket (outside of Croquet) to the
common external VNC server. In this case, the shared session state
is maintained by the VNC server, and the Croquet code built on top of
TEMbeeddedApp deliberately avoids replicating input to the embedded
app (the remote VNC server) so that you don't get multiple characters.

Your Putty terminal example is somewhat between these two. But since
VNC is a superset of what you need, it's a good way to prototype
something.

For example, you could display a Web browser with an issue tracker in
one, and a terminal emulator in another. You could also use the
simple text panels as a free-form issue tracker, or later build
something more specific that would be programmed to communicate
separately with Scarab or other programs.

>
> 4.) Is it possible to trigger a local program from Croquet (i.e.
> popping up a local putty
> window, or a browser) when grabbing at something in the
> Croquet-world?

Yes.

>
> 5.) Is it possible to alter the Croquet canvas in a way that is
> more "standard", i.e.
> i'd like to replace the function buttons around the Croquet
> window by more conventional
> buttons and possibly menu popups if necessary. This is just a
> concession to casual
> user expectations.
> I know from former experiance with our customers that they
> want to see the entry level
> as low as possible. Hence i'd like to reuse the standards for
> (wiondows-)gui, i.e. move
> the window closing cross from upper left to upper right, add
> frame around the
> Croquet-window from where i can move the window and control
> the window
> size as expected from todays standards.

Yes. One of the Croquet architects is also an architect of a major
new graphics and windowing system for Squeak, called Tweak. Three of
the demos (KAT, Sailing, and Simple) all use Tweak to provide a
conventional menu bar as well as context menus for objects.

Tweak in Croquet has its own cross-platform default look and feel
that is not quite Windows nor Mac nor Gnome nor KDE, etc. You can
customize this through programming.

You can also programmatically define your own button arrangements for
the flat window panels that you see in Croquet. For example, the KAT
demo windows are deliberately missing the camera button that appears
on window panels in the other demos. Some of the demos also have a
slightly different or missing 'dock' that appears at the bottom of
the Croquet display when you move your mouse there, etc.

> It would even be nice when i could simply start
> an individual Croquet-world in a separate window instead of
> within the Croquet-sdk. Is
> that possible ?

This is not my area, but I don't see why not, with work. As is,
though, you can easily program the Croquet display to be any portion
of the Squeak application, including the entire application window or
even full screen. I think all of the demos will let you interactively
change them to full screen, but they differ in how you do so.

>
> 6.) Is Croquet already stable and mature enough so that we can
> build such an app
> around it and use it in production scenarios ?

I feel so, but there are several dimensions to consider:

* Look and feel: as discussed.

* Reliability: The general SDK has a number of known issues. But your
application is considerably more constrained than a general demo or a
public environment like Second Life. This allows you to test
throughly and guard against any specific problems you find.
For the core of Croquet, my own expectation is that if you develop
this yourself, you will run into bugs during development, but that
there is nothing you will not be able to fix yourself or work around
such that your customers will not encounter bugs. With good
conventional quality control techniques, I think the engineering of
the Croquet SDK platform is such that your customers will find it far
more reliable than most other commercial applications. However, I
feel that it is only with the current code base that this has become
the case -- there were reliability issues in earlier development
versions in previous years that I, for one, was not experienced
enough to avoid in our pilot-project deployments.

* Repeatability/Deployability: The Squeak core is phenomenally
portable and consistent on a very wide variety of platforms and
configurations of those platforms. Croquet also uses surrounding
technologies that are not implemented completely within Squeak/
Smalltalk. For example, it is dependent on OpenGL and OpenAL, which
requires correct configuration of drivers, libraries and such that
can vary from one machine to another. Webcam video or other add-ons
require "squeak plugins" that vary from one computer platform to
another. Supporting these over a large and arbitrary deployment base
may require special care.

* Support: Being completely open source, with a talented developer
community, I feel that you are much more likely to get issues
addressed as you need than in a closed commercial product. However,
resources are often not immediately available for specific non-core
fringe technologies, such as platform-specific plugins.

* Performance: LAN performance and the performance of all other
Croquet demo objects have always been good. I am only now doing the
first tuning of WAN performance for the KAT demo, which was certainly
not acceptable before. Similarly for the VNC panels. However, I
believe that there are private/commercial applications of Croquet
that have excellent WAN performance.

* Security: If you and your customers are running on Windows, or as a
browser plugin in Internet Explorer, then Croquet security is not
relatively an issue. Nonetheless... Croquet traffic is encrypted in
a manner that I believe is roughly equivalent to SSL. The SDK
includes a simple username/password session login, that is simply
hardcoded in all the demos. Assuming you trust your customers and
vice versa, I think your scenario is quite secure if you build
something with a secure session login. (This version of the SDK is
NOT secure in an absolute sense for open arbitrary communication
among untrustworthy peers, but is probably no more so than other
applications of similar scope.)

>
> 7.) Is it possible to create a plugin which runs Croquet within a
> browser
> (namely iexplorer-6 and firefox) or does such a plugin already
> exist ?

Yes, this is possible. A Squeak plugin for Windows browsers already
exists, and several of us have used this in earlier versions with
good results. I understand that there is also now a Squeak plugin for
Macintosh browser, but that it may or may not have issues displaying
the OpenGL graphics that Croquet depends on.

> Just curious: Would it be feasible to create an eclipse-plugin
> for the
> Croquet-viewer ?

What is the usage scenario?

>
> 8.) How do two Croquet-worlds communicate with each other
> technically, i.e. do we have to open
> specific ports on our firewalls to allow interactions ? Or
> does Croquet use port 80 for
> underlaying communications ?

On a WAN, one machine must be able to accept multiple connections on
a port that you (as a programmer) specify. Everybody else must be
able to reach that one port, but they themselves can be behind
firewalls, NAT, etc.

(In the discussion lists you may see that LAN also does some
broadcasting for discovery, and other versions have done hole-
punching and used additional ports. But this is not relevant to your
use case.)

External applications (VNC, putty, etc.) do what they do separately.

Your scenario also calls for voice and perhaps video. These are
handled in the demos as ordinary Croquet traffic. No additional ports
are involved. However, other specialized and tuned applications might
use additional channels for these.

>
> 9.) Is there any published time schedule for the ongoing
> development in Croquet ?

No.

>
> 10.)Are there already developers around Croquet who may be
> contacted for helping to realise
> such a project ?

Yes.

Julian Lombardi (croquet@...) is forming the non-profit Croquet
Consortium and can put you in touch with developers worldwide.

You can also solicit help on this list.

I encourage you to see if there is a commercial fit with
http://qwaq.com
or
http://impara.de

>
> If you have read until here, i thank you very much for taking your
> time and i would be
> pleased to get some answers.
>
>
> best regards,
> hussayn

Please feel free to contact me,

Howard Stearns
University of Wisconsin-Madison, Division of Information Technology
+1-608-262-3724

Re:using croquet as an interaction platform for issue tracking ???

2007-01-10T01:35:16Z

Hi, all;

I am brand new to VR in general and to Croquet in special, although i am a programmer
having about 30 years of experience with all sorts of software development starting with
microcomputer programming in the midth of the 70's and ending up running a small software
development company specialised on webapplication technology.
So recently i took a brief look into some VR technologies, especially second life has
attracted me in first place which IMHO is very impressive namely its look and feel. That's
nice for leisure, but i am not quite convinced regarding second life as a platform for
serious working in the first world ;-).

So i turned to Croquet and found its key technology much more interesting especially
because i am interested in a concrete scenario, where i want to make the interaction
between our software development and our customers more efficient. And i believe, Croquet
could do something for us here in a much better way than other solutions can do. But as
a newbie in this field i am unsure whether i am really going the right way. Hence i took
some time to bring my beginner's ideas to this email hoping to get some brief answers.

So here we go: I think about a virtual issue tracking system involving direct virtual
interaction between customer and developers. I'd like to verify whether the following
use case can already be implemented with todays Croquet implementation:

The use case
============

We are currently using a web based issue tracking system (namely Scarab, maybe you have
heard about it ?) for communication between our development and our customers. Very often
text based issues are not expressive enough to understand the problem. Hence we need to
get to the phone and let us explain in lengthy words what the customer problems are all
about. Often we need to place ourselves in front of the Browser and try to reproduce
described effects on the customer system. We have a connection via VPN and thus can get
into the customers computer system for maintenance purpose. This scenario has prooven
efficient regarding to the main stream tools as available today (browser, webapplications,
telecomunications, vpn, ...), but i like to push this (much) further:

1.) I want to create two virtual worlds, i.e. two rooms in Croquet:

- development lab where a customer can take a look into our ongoing work, e.g.
play around with our development system (a webapplication). This playing may be
acompanied by a developer, who shall comunicate how to use the frontend by
using his developer avatar, while the customer avatar may listen e.g. via voip
The customer may also utilise our testsystem either directly from the web, or
through a viewport from Croquet.
The development lab shall physically run on one of our company servers.

- customer lab where a customer offers a direct view to his production and
test systems. The main functionalities are technically more or less equivalent
to what we want to offer in the development lab above.
The devleopment lab shall run on one of the customers computers.

2.) The development lab and the customer lab shall be connected via a portal, thus
customers and developers can enter both rooms whenever needed and start a comunication
with others when online.

3.) a user (developer or customer) can leave a message to another user at any place. This
message shall be physically organised in our issue tracking system, which is also web based
and allows to enter issue related comments, upload/download any files.

4.) through the customer lab we shall get direct access to e.g. a terminal window from where
we can start a terminal session either directly in Croquet or on an external window which
runs a terminal software (e.g. putty)

Some questions
==============

The above scenario is just a rough sketch about what i have currently in mind. One of the
crucial points is about acceptance of such a system. So here are my essential questions:

0.) Does it make sense in first place ?

1.) Is it possible to create a custom croquet containing our own avatars instead of the
original ones coming with the Croquet sdk ? Can we also remove the demo worlds and
just keep a template for the customer-room? Such that we can let our customer
download the Croquet viewer, start it and get right to where we want him to go
without learning anything about croquet, just jumping in and start with the intended
application ?

2.) Is it possible to efficiently connect Croquet viewing portals with a Webapplication
running in the same domain as Croquet runs in ?

3.) Is it possible to connect a Croquet Viewing portal with a terminal program, i.e. putty ?

4.) Is it possible to trigger a local program from Croquet (i.e. popping up a local putty
window, or a browser) when grabbing at something in the Croquet-world?

5.) Is it possible to alter the Croquet canvas in a way that is more "standard", i.e.
i'd like to replace the function buttons around the Croquet window by more conventional
buttons and possibly menu popups if necessary. This is just a concession to casual
user expectations.
I know from former experiance with our customers that they want to see the entry level
as low as possible. Hence i'd like to reuse the standards for (wiondows-)gui, i.e. move
the window closing cross from upper left to upper right, add frame around the
Croquet-window from where i can move the window and control the window
size as expected from todays standards. It would even be nice when i could simply start
an individual Croquet-world in a separate window instead of within the Croquet-sdk. Is
that possible ?

6.) Is Croquet already stable and mature enough so that we can build such an app
around it and use it in production scenarios ?

7.) Is it possible to create a plugin which runs Croquet within a browser
(namely iexplorer-6 and firefox) or does such a plugin already exist ?
Just curious: Would it be feasible to create an eclipse-plugin for the
Croquet-viewer ?

8.) How do two Croquet-worlds communicate with each other technically, i.e. do we have to open
specific ports on our firewalls to allow interactions ? Or does Croquet use port 80 for
underlaying communications ?

9.) Is there any published time schedule for the ongoing development in Croquet ?

10.)Are there already developers around Croquet who may be contacted for helping to realise
such a project ?

If you have read until here, i thank you very much for taking your time and i would be
pleased to get some answers.

best regards,
hussayn

Online Gambling-Online Black Jack-Black Jack Casino-Online Slots-Slots Online

2007-01-02T08:27:03Z

David Faught wrote:

On 11/2/06, Howard Stearns wrote: > >> I am working on a new design that allows multiple separate islands to be > >> coordinates by a viewing window (an "interactor"). The common stuff is > >> viewed by everyone as they join the island. A different set of content > >> to be superimposed is in a different island. The interactor renders > >> both islands, coordinating the local execution of the two island clocks. > >> Finally, one can drive through the interactor so that it's sort of > >> pasted to your camera lens rather than fixed in island-space, such that > >> you don't need to stand to the side to see both worlds, but rather can > >> walk around and interact with both. Security is achieved through the > >> interactors. You only give out the interactors to those whom you want to > >> have access. (And the interactors might be non-assignable, revocable, > >> etc.) > > > This interactor is a general viewing mechanism -- a generalization of > TPortal. They stack, just like TPortal does. The toplevel applicaton > window is really just an interactor that's stuck on your camera lens (no > TWindow frame). > > You can have any number of TPortals to an island, and they can be on the > island itself. (For a while there was a little bug that prevented this.) > Interactors are no different. So I don't think it is any more > complicated to use than TPortals now. The basic idea of the interactor is interesting to me. I read the "Filters and Tasks in Croquet" paper a few times, as well as the earlier referenced papers on Magic Lenses. I like the idea of the interactor getting "pasted onto your camera lens" and allowing stacking of interactors. Particularly for developers, I could see using a series of interactors like the wire-frame view, the boundSphere view, the little arrows representing normals view, etc. I can easily visualize how these could be used individually and stacked. Maybe 3D painter or mesh deformer interactors could be built. But I don't really understand how this idea is brought out in Croquet. I have the general impression that David A. Smith is doing further work in this area that will eventually dramatically change things. On the other hand, you tell me that you have already done this in Dormouse and I know that Mark McCahill and team have done some of this in Hedgehog with thumbtack annotation. This is an area that I would like to someday explore further, but what should I use as a starting point? Or is the real starting point just not ready for public use yet? Somewhat related to your two-island security model, I have been thinking about how to implement a simple example collaborative Texas Hold'Em poker game. The cards have to exist in a replicated island in order to be dealt from a common deck and for scoring, but different participants have different rights with respect to viewing the cards and these rights may change at different points in the game. And the chips can be viewed by all participants, but only manipulated by their owner or the dealer. This is so far just an idea floating around in the back of my mind, but it seems like a good and fairly simple example to explore the whole area of security in Croquet. And as a meaningless parting shot, why is it "putting in my two cents" but only "a penny for your thoughts?" I definitely value your input more than mine!

Online Black Jack

Where to buy viagra
Buy cheap acomplia
Buy cheap generic acomplia
Generic Pharmacy Online
Buy viagra where
Buy cheap viagra where
Buy cheap viagra where
Buy cheap acomplia
cheap generic acomplia
Order cheap acomplia
Order cheap Albenza

Re: GL_ARB_transpose_matrix redux?

2006-12-22T09:48:50Z

Howard Stearns wrote:
> I don't know what it's telling me, but I don't much like lines at the
> end (see <<< just below):
[...]
> OpenGL vendor: Microsoft Corporation <<< GLView reports "Intel"
> OpenGL renderer: GDI Generic <<< GLView reports "Intel
> 945GM"

That is just what I expected.

> How come GLView can find a "good" renderer (whatever that is), but we
> can't?

I don't have the time to look at it in detail (got to catch a flight)
but it's most likely the stencil buffer requirements.

Cheers,
- Andreas