[EMAIL PROTECTED] wrote:
> Hi JBone,
>
> you wrote:
> >Look, here's *just one* way to handle these issues. (There are plenty of
> >others.) HQ writes specs.
>
> We'll call ourselves HQ for now and write specs.
>
Dude, clue: my point is that this is wasted effort on the DB front in terms of
defining APIs for Rebol that Rebol Inc. wants to write. Do You Understand My
Point? How would you like to spend a lot of time (a) developing the API and
its implementation, (b) developing apps that use that API if (c) in two months
your API and its implementation was going to be made irrelevant and (d) you had
to go and rewrite all your code? I really don't think this is that hard to
understand.
>
> >HQ manages builds.
>
> Since REBOL is a scripting language and my contention is that building DB
> support into REBOL can be done as a script using the existing port
> mechanism (would require some more investigating), there is no compiling,
> there are no builds.
>
Sigh. In my scenario, I'm talking about builds of the Interpreter. 'K?
>
> >HQ makes official builds
> >available.
>
> Same as above.
>
> >HQ writes whatever code they want to put in there.
>
> If we're serious about this, we can ask REBOL Tech to monitor our specs and
> enter into a dialog about DB specs. They can put whatever code they want
> into their release.
>
> >HQ selects from
> >contributed code, taking what they like.
>
> Now, we're talking about REBOL Tech. REBOL Tech selects whatever code they
> want for inclusin in REBOL Tech distribution.
>
> >HQ sells binary distributions, support,
> >applications, additional devtools, maybe a compiler.
>
> Here again I'd replace HQ by REBOL Tech. If they choose to integrate our
> OpenSource DB API, they could integrate into binary distributions as far as
> I'm concerned.
>
> >Runs a web-based community.
>
> We have rebol.org.
>
> What do you think?
>
> ;- Elan >> [: - )]
I think you're missing the point, Elan, frankly.
jb
