> From: Ralph Versteegen <[email protected]>
> Sent: Sunday, January 10, 2010 1:39 AM
>
> 2010/1/10 Jay Tennant <[email protected]>:
> >> From: Ralph Versteegen <[email protected]>
> >> Sent: Saturday, January 09, 2010 12:09 PM
> >>
> >> 2010/1/8 <[email protected]>:
> >> > jay
> >> > 2010-01-07 18:56:04 -0800 (Thu, 07 Jan 2010)
> >> > 195
> >> > Adjusted backend test gfx_getversion() to require a bitwise OR-ing with
> >> > 1 as the supported version. Added new function gfx_LoadDllBackendProcs()
> >> > as a generalization of gfx_directx_setprocptrs().
> >> > ---
> >> > U wip/backends.bas
> >>
> >> But that scheme we limit us to changing the version 32 times :)
> >
> > I'm hoping we don't need to change interfaces more than once (in which case
> > we have version 1 and 2). What else is the backend supposed to do besides
> > render an ohr-rendered image to the screen? Besides, with each revision
> > aligned with a release, I don't think it'll matter in 32+ years.
>
> I thought the idea was that the version would be incremented whenever
> we changed something. Example: I decide I'd rather gfx_Screenshot
> return the actual filename saved to instead of success/failure, so I
> change it on the spot and increment the interface version number and
> update all backends. This is how we've been doing things up to now
> (minus the version number).
Why would a backend need to keep track of changes between releases?
> Defining an interface and setting it in
> stone is terribly constricting; I'd rather that we be able to change
> it continuously.
It is restrictive. That doesn't mean it's crippling. A set of defined
interfaces identifies how the module should interact with the rest of the
modules. If all the modules know what to expect, they can communicate
efficiently.
It's the same thing as playing an instrument. A piano has 88 keys to interface,
plus 3 pedals. One can perform amazingly on it because they study for years on
that simple interface and understand how the piano is supposed to respond to
their communication. The piano's interface hasn't changed for almost 200 years.
The goal, therefore, is defining an api that the backends can implement, and
the engine can communicate with. We have until the next release to figure out
the api.
> But I think that now I understand why you wanted this
> message passing system: you weren't thinking of this.
I still think this is a necessary system--it's tremendously flexible, yet
simple. And if a certain message isn't supported, the engine's default message
processing would take care of that.
> We can change the interface whenever we want, not just at new
> releases. And remember that many people use nightly builds, so we
> effective release a new version every day.
But they effectively receive a new version of the backends every day then, too.
To those using the nightlies or svn, changes to the interface definitions and
backends will be transparent. Therefore it's unnecessary to increment the
version when an interface is updated from day to day between releases. Can you
imagine the backend support headache that could possibly generate?
> And as aside, I think we prefer to release a few times a year rather
> than every year; it definitely wasn't desired that Ypsiliform take a
> year.
Oh, I see.
> >> The new interface is an exception; generally it won't be possible to
> >> support two versions at once. We could do:
> >>
> >> 1: current interface
> >> 2: supports both current and new
> >> 3: new interface
> >> 4: next revision
> >
> > For the next complete release (not a "Ypsiliform + tourniquet" in the event
> > of an emergency bug fix), version 2 should be the accepted interface, not
> > version 1.
> >
> > You're right, though. There's no need to support both old and new
> > interfaces in the same backend. Perhaps the backend test should just test
> > for 1, not a bitwise OR with 1 after all.
>
> Alright, that seems much cleaner.
>
> > Then we can allow the integer to register 4billion interface revisions, lol.
_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
