-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, I finally have a chance to reply to this thread :-)
On Sat, 8 Apr 2006, Lalo Martins wrote:
On Mon, 03 Apr 2006 18:10:57 -0400, Peter Amstutz wrote:
* Ditch CVS in favor of SVN or BZR
I think this is orthogonal to any other goals.
True, but it is potentially disruptive and takes up development time just
like anything else.
- - VOS core
* Rewrite site connection management to use public keys instead of
hostnames as discussed previously
I'd like to see this one sooner rather than later.
I am inclined to agree. It would be a radical change in the protocol,
which is better to do now rather then later when we have lots of users.
Also this would be an opportunity to introduce message signing and/or
encryption.
- - Scripting
* Bring Python bindings completely up to speed so that they can be used
to write omnivos plugins, parts of ter'angreal etc
This gets my vote for the .24 goal; but of course we enter the discussion
of whether the swig bindings are even capable of doing what we're talking
about. I still think you can't wrap an existing Vobject as a python
object, then call python code from C++ passing this wrapped object. I
just couldn't find a way to do it.
Well, it depends on what you are trying to do. I you trying to define a
new metaobject API via Python, then no, you can't do that easily. On the
other hand, SWIG can handle subclassing (!!!) C++ classes into Python, so
if you define some API in C++ first and let SWIG know about it, then you
could have the actual implementation in Python and it would do what you
want. Obviously, since C++ is a static language and Python is a dynamic
language, you can't do everything you want, but that's the whole point of
embedding Python in the first place.
It's worth noting that I have been toying with the idea of adding some
sort of Interface Definition Language (IDL) which could then be processed
to generate marshaling code for both cross-network and cross-language
function calls. I haven't come up with a good use case where this would
be a vastly superior approach to what we are doing now, however.
Also SWIG is in some ways exactly that glue/marshaling in generator, it
just happens that C++ *IS* its interface definition language. You could
probably even write a SWIG module that generated VOS RPC marshaling code
for a C++ API...
Whether it's possible or not, I'd be more than happy to merge my scripting
code on vos. If swig turns out to be usable, then we just ditch the
wrapping parts and keep the rest.
Of course. I'll take a look at it soon.
- - 3D rendering
* Add native animation to A3DL
* Add skeletal models to A3DL
* Add terrain to A3DL
* Add prims (via FractalSpline) to A3DL
* Add trees (via OpenTreeLib) to A3DL
* Add humans (via MakeHuman) to A3DL
* Support for more import 3D formats to A3DL, such as VRML/X3D, 3DS,
Quake maps, Collada, OpenFlight, FBX...
One or more of these would get my second-choice vote. But I suppose it's
more interesting to have powerful scripting first, and then from .25 on
focus on these, because having scripting will make them much more useful,
and help with testing.
- - User interface
* Add a concept of a "user agent" to A3DL which is an object
which specifically reperesents the 3D browser application and what is
being displayed to the user
* "Clickable" type, would indicate a 3D object (or other interface item)
was clickable and would send a message back saying it was clicked
These also sound lovely, but would largely benefit from powerful scripting
already being in place.
The user agent change is likely to happen anyway, as it would make certain
code in ter'angreal a bit simpler. The clickable is very easy, and if
scripting goes in, may well happen so that you can actually do something
with that scripting.
* Start using AWS2, the next-generation Crystal Space which defines
and
renders UI components with fragments of javascript, would allow the
client to download a UI from a server to reconfigure itself on the fly
I'm not extremely excited about this.
It's not high priority for me either, not the least because AWS2 is still
under development so it won't be really usable for a while.
* Rewrite ter'angreal in python (since CS+VOS+Wx all have Python
bindings)
Are you trying to throw me a bone here? :-D
Well, I really want to get to a point where other people can work on
ter'angreal, and if building everything in C++ is too hard, then a
possible solution is to write the end-user application in an interpreted
language so that you don't need the whole development environment to
contribute.
On the other hand, getting everything talking to each other in the
resulting mix of Python and C++ might not be feasable. For example, a
wxWindow* from the wxWidgets bindings might not be recognized as such by
the Crystal Space SWIG bindings... Although it might still be doable with
a C++/Python hybrid that dealt with those edge cases. At this point I'm
just throwing out ideas.
But if a complete rewrite is even considered, then I'd ditch CS too; it
doesn't seem it will ever be stable enough.
The problem with stability in CS is more that I have insisted on tracking
the CVS version, and I think that was a mistake. For this next
development phase, I am considering importing a CS snapshot into the VOS
tree, and developing against that. Then we don't have to deal with it
changing and breaking stuff all the time.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEQ8DYaeHUyhjCHfcRAh1IAJ4tpol5pqJjwzBus2F6WCEc2czAtgCfT7nx
wM3khmzoHqccpB8ETayTg/s=
=Rq4l
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
