Re: Ideas on the future of Quesa.

[Jose' C. <cru...@ce...>]

Il giorno 29/nov/04, alle 13:21, Dair Grant ha scritto:


> So, I think the time has come for me to move on from Quesa - and to
> leave it in the capable hands of the other developers.

Dair It has been a great pleasure work with you,
Looking forward to meet you some time by person (I'm 45 mins away from=20=

Bergamo, that is 19=80 away from London (ryan air), if you want a=20
Spaghetti meal, just email me) (invitation extended to anyone else in=20
the list)


> But here we are, 5 years on, with shipping apps built on top of it: so=20=

> I
> think that has to be a success. :-)

I think so..

> - Don't lose abstraction unless you really need it. I'm quite pleased
> with the way the internals turned out, in that we kept a very OOish
> style internally (where each .c file exposes some opaque types and
> functions to work on those types; so geometry code doesn't see any
> details of cameras, etc).

yes it has been a good work on your part

>
> - Keep the plug-in renderer idea. This is one of the nicest things=20
> about
> QD3D/Quesa IMO, the idea that the organisation side of things is
> completely separate from the rendering side.

Absolutely


> - Keep the history. Even if you move on to using subversion at some
> point, I would recommend keeping as much of the CVS history as=20
> possible.
>
> We don't go all the way back to 1999, which is something I always
> regretted, but I think it's useful to be able always get back to older
> versions. If some planned development doesn't work out, that means you
> can then rewind N months and easily start again.

Absolutely... I've every single public mail about quesa archived since=20=

your original announce

>
> - Keep the licence. Switching from the LGPL to BSD solved a lot of
> problems for me at work, and allowed me to use the math sections of
> Quesa in our D3D->GL translation library. The GPL licences wouldn't
> have.
>
> - Think about a CoreFoundation approach. Something that's worked well
> for Apple is to have a CoreFoundation library which provides basic
> primitives (strings, sets, etc) and then have other libraries built on
> top.

>
> - 3D math library. All the standard operations, intersections, etc; =
you
> could see this growing into more general purpose fields like collision
> detection, visibility tests, or physics.

Absolutely

>
> - 3D file format parser (harness that would register N plug-ins for
> doing IO, the plug-ins parse their data and return it back via=20
> callbacks
> with some type info.
>
> Means that people could link to the file format library, and get =
called
> back as objects are parsed out of the file; the object description
> allows them to build their own data structure out of it. Quesa would
> also link to the file format library, and have a set of callbacks that
> build Quesa objects out of the data.

I think it's simpler to build quesa objects and let's others extract=20
from there that declare a bunch of call backs

>
> I know we moved the Viewer library into Quesa so we could have a =
single
> shared library for users, but think of these more like the plug-in
> renderers.
>
> I.e., a well defined interface between them and the rest of Quesa, and
> build them (and perhaps even the plug-in renderers) as static =
libraries
> that then get linked into the Quesa shared library.
>
> For this to work the interface would need to be 100% independent; =
i.e.,
> you would need to be able to say "I just want to use the math library"
> and know exactly what headers/.lib files were needed for your app (and
> the math library couldn't call anything in Quesa; it would have to sit
> under everything - perhaps need a CF-style library to hold truly =
common
> bits below these utility libraries).

yes it's a clean approach


> - Don't go crazy. :-) One of the problems with C++ IMO is that it's=20
> very
> easy to create systems that are just unmaintainable. Everyone feels
> differently about what's good and what's bad about C++, but I've seen
> plenty of projects that just got out of control when they started=20
> taking
> a "C++ purist" view of things rather than the pragmatic view.
>
> The STL is definitely a useful source for all the standard data types
> (lists, vectors, hash tables, etc), but I would be wary of going
> overboard with stuff like operator overloading.

Absolutely I'll always vote for C+-


> But for now, have fun - and good luck!
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602