Open-GTO: The first version?

[Mike]

OK, now that we have this spiffy new place (it still has that new-car
smell!), what's the next step? Other than getting the code moved
over, that is.

What will the first version of Open-GTO be called? open-gto-1.0?
open-gto-3.[56].x? open-gto-4.0?

I volunteer to work with the autoconf garbage and build release
tarballs once Jim gets the headers changed and into to hg.

-mike

[Christopher Horvath]

I think having an Open GTO 1.0 release would be good press-release
fodder. Streaming and multiple protocols (if we can decide what that
means) are big enough features to warrant that kind of attention, and
it gives us a little nudge.

I was about to start a discussion about boost-build, which you all
know I love, love, love. (really!) But yeah, one thing at a time.
Autoconf.

[Joe Ardent]

On Thu, Aug 20, 2009 at 5:05 PM, Mike<mike...@gmail.com> wrote:
>
> OK, now that we have this spiffy new place (it still has that new-car
> smell!), what's the next step?  Other than getting the code moved
> over, that is.
>

I'd say that getting the code moved over, and building it, would be a
good, big first step (build to ensure that it compiles without errors
or warnings with the latest gcc; maybe we could also have offer some
pre-built binaries?). Then the hard part: naming it.

> What will the first version of Open-GTO be called?  open-gto-1.0?
> open-gto-3.[56].x?  open-gto-4.0?

Since this is a new project, I vote for "open-gto-1.0". Minor version
numbers (the "0" in the previous example) to indicate bugfix releases,
and major version number for anything that would break binary
compatibility?

> I volunteer to work with the autoconf garbage and build release
> tarballs once Jim gets the headers changed and into to hg.

I would be happy to help with this. If we wanted to make it available
via git/github, I could try setting up a mirror from the hg repo if
there's interest in that.

-Joe

[Christopher Horvath]

So wait... are these google project management tools WORKING?

On Aug 20, 5:47 pm, Joe Ardent <ard...@gmail.com> wrote:

[Mike]

I'm happy with open-gto-1.0. In order to get there, we need a list
of targets. Multiple protocols and streaming are definitely on the
table. Multiple protocols is easy. I haven't thought a ton about
it, but we need to find a way to do both streaming AND random access
to property data. Other than Jim's (very honorable) quest to drive
quicktime into the mud, what would people need streaming GTOs for?

What about all the other stuff? We should make a list first, identify
dependencies and blockers, and pick what we can do, say, by the end of
the year, if not sooner. Let's not try and put the whole world in at
once, or we'll never get it done.

-mike

On Aug 20, 5:47 pm, Joe Ardent <ard...@gmail.com> wrote:

[Jim Hourihan]

I don't know if my other reply worked from the web interface so I'll
reiterate: we obviously don't want to change the file version scheme
to 1.0 right? We need to maintain the version line for backwards
compatibility. So why not just call it what it is: version 4.
Otherwise we basically have to make unnecessary name changes which is
a waste of effort.

There's plenty of stuff to work on here other than administrative
garbage. Let's concentrate on adding features. None of us has time to
waste.

-Jim

[Christopher Horvath]

I think we should view this, on some level, as a semantic upgrade.
Even though
all of us have been working on this in the same spirit as we will
continue to, this
does represent a coordinated push forward with a specific focus
towards building
a larger, more self-sustaining community. That aspect of this
development is
a very new feature of what we're doing, and it will be reflected
across the board.
It will affect protocol design and ratification, it will affect
adoption issues in vendor
tools, and it will make this a community effort beyond just something
cool and
very useful that we've done.

I can see the problem - if we have gto files that have a version
number in them
that says 1.0, but with ".gto" extension, it will confuse people, and
they'll think that
we've somehow gone backwards. However, I think we're going to change
enough
of what we're doing that we can literally change the ASCII file format
to say
OpenGTO(1) at the top, instead of GTO(4). We can (and should) change
the
magic number in the binary files, and we should maintain as much
backwards
compatibility as we can with regular GTO versions 3.5 and earlier.

I view this as exactly analogous to the switch from IrisGL to OpenGL.

Lastly, I think any and all communication from this point forward
should take place
in these open forums, as far as design and strategy is concerned,
including all
of our "public outreach" decisions. This is very much a feature of the
(as yet
unspecified) goals of this project. I'm going to quote the COLLADA
spec here.
We don't share all of the goals of COLLADA, but we have many in
common,
and I agree with how they've included adoption as part of their design
specification:

----From the COLLADA 1.5 documentation
(spec)--------------------------------------
Goals and Guidelines
* To liberate digital assets from proprietary binary formats into a
well-specified, XML-based, royalty-free, open-standard format.
* To provide a standard common language format so that COLLADA assets
can be used directly in existing content tool-chains, and to
facilitate this integration.
* To be adopted by as many digital-content users as possible
* To provide an easy integration mechanism that enables all the data
to be available through COLLADA.
* To be a basis for common data exchange between 3D applications.
* To be a catalyst for digital-asset schema design among developers
and DCC, hardward, and middleware vendors.
-----------------------------------------------------------------------------------------------------------

We realize that the scale of assets that we deal with mandates a
compressed, binary format. As such, XML is unsuitable.
However, other than that point, every single design point listed here
applies to us so completely, that I hope we can
place COLLADA<->GTO interoperability high on our list of future
features so that the two might one-day merge, since
they have ultimately the same philosophical goals. While GTO handles
the job better for large assets and simulation
data, COLLADA have done a significantly better job at the getting-it-
out-there aspect, and that's ultimately what I think
the switch from GTO to OpenGTO is all about.

C