Modules created and initial files checked in

[Kevin E Martin]

On Sun, May 08, 2005 at 06:10:23PM +1000, Daniel Stone wrote:
> On Thu, May 05, 2005 at 09:49:58PM -0400, Kevin E Martin wrote:
> > If you have any questions, suggestions or comments, please feel free to
> > post them here.
> 
> Haven't really had time to look at all this before now, but I spent some
> time on it on the weekend.
> 
> Firstly, how are we going to version the individual components?  I think
> that we should continue as we've been doing, with, e.g. version 2.2.1
> for libXv, 2.2 for the Xv proto, et al.  The alternative, of course,
> being 6.9.99.1 (e.g.) for all the modules, but then you start bumping
> the version number even where there haven't been any changes.

That's a really good question.  When I created the initial proto module
components, I just used 7.0 for the version numbers to get the ball
rolling, but I think you're correct that it would be better to use the
library versions as a starting point for the corresponding proto
packages.  Note that as we move forward, the protocol and library
version numbers will probably get out of sync since we can make major or
minor changes to a library without a corresponding change to the
protocol headers (e.g., deprecating library functions or adding new
functions that make use of the existing protocol).

This re-raises the issue that I raised in an earlier thread regarding
library headers being intertwined with protocol headers.  Ideally the
protocol and library interface headers would be separable, but right now
they are not.  Making all headers separable (and moving the lib headers
to the lib module) could cause problems for ISVs who include the proto
header instead of the lib header.  I would like to see this fixed, but I
don't know if this is the appropriate time.  What do others think?

> One comment: can we *please* not call the MIT-SCREEN-SAVER protocol
> module, 'SS'?

Sure.  What would you suggest as an alternative, ScrnSaver?

Just in case it's not clear, we're now in the development phase and
everything should be considered changeable.  At some point we should
start locking things down, but we're far from that point today.  So, if
anyone sees something that could be done in a better way, please follow
Soeren's and Daniel's examples and post suggestions here so that we can
discuss them.  And, anyone who has an alternative solution or objection
can raise them.  If no one raises objections or proposes alternatives,
the person who made the suggestion should feel free to go ahead and
check in the suggested change.

> Other than that, looks good, and I was banging at the server two weeks
> ago and yesterday, and I've got a cleaned-up server core that links now.
> Will post the symlink.sh modifications when I get time.

Excellent.

Kevin