[EMAIL PROTECTED] wrote:
> >Part of the reason that you aren't seeing a plethora of solid,
> > commercial-grade Web apps in Rebol is the lack of key functionality
>
> Since you bring it up, I thought it was lack of GUI support? :-)
>
Well, *obviously* the lack of GUI support isn't what's holding up Web app
development. :-/
> Wonderful. Isn't OpenSource all about volunteers providing commercial
> quality software? Why then do you delegate the functionality you are
> desperately seeking back to REBOL Tech?
Elan, I'm not sure where you're headed with this, but I'll take a stab. Surely
this argument is clear. I have no problem going out and building DB support, or
whatever else I might need to build Web apps. But I'm certainly not going to
waste my time --- now and in the future, retooling --- building out and using an
API that is going to be superceded by an officially-supported API in platform.
And therein is the biggest problem with closed development, and the best argument
for open source; instead of having a whole group of developers blocked on a
vendor saying, "we're going to do it, but you have to wait for it" you have a
community --- which includes the vendor and the 3rd parties in question ---
collaborating, and things happen in parallel.
> >This would be kind of silly
>
> Oh, yes. Would it?
>
Well, unless you just happen to like wheel reinvention. I don't, but maybe you
do...
> >Does it really make sense to invent an idiosyncratic 3rd-party API for
> >something
>
> Certainly not. But I didn't propose that what we invent be idiosyncratic. I
> agree with you. Let's not make it idiosyncratic. Ok?
Well, it will by definition be idiosyncratic with respect to whatever the
"official" API ends up being. How'd you like to crank out a few thousand lines of
hairy application code written on top of the 3rd party API, then have to for
whatever reason (better performance, etc.) replace it whenever the "official" API
issues forth from HQ?
On another front, I think there are very good arguments for keeping the APIs for
Rebol unified at this point. Having two APIs for the same thing is simply
divisive at this point in the language lifecycle. This doesn't argue for or
against open source; it merely argues for a single authority for common APIs.
Here's a thought: if Rebol Inc. would at least give us (a) an official spec for
what they think the DB API ought to be, (b) a mechanism for dynamically linking
and invoking native code modules, and (c) a C API to the Rebol interpreter
internals, somebody else could go and build the very same API that they apparently
have in mind but don't have the resources to complete at this point.
> >when it is going to be obsoleted by technology that's already been
> >announced by the tools vendor in question?
>
> I don't understand. On the one hand, we get people proposing that the whole
> REBOL interpreter become OpenSource. What for, if not for continued
> development? Wouldn't the continued OpenSource development include
> functions that the "tool vendor" intends to eventually implement? I should
> hope so.
Again, I really don't see where the confusion is coming from.
> Looks to me like your argument doesn't accomplish much more than call the
> whole OpenSource approach silly:
And I don't see how you arrive at this conclusion at all... the problem comes
from closed development with particular tasks on the agenda but without resources
to meet the scheduling needs of its user community. That's one of the *very same*
problems open source solves.
The problem (and my contention) is that, in a closed, proprietary platform, IMO it
doesn't make sense to redundantly develop code that the vendor is going to
obsolete themselves in a few months. Better to wait... and nudge. ;-)
> If REBOL went OpenSource, everyone but REBOL Tech is allowed to continue
> developing it?
Look, here's *just one* way to handle these issues. (There are plenty of
others.) HQ writes specs. HQ manages builds. HQ makes official builds
available. HQ writes whatever code they want to put in there. HQ selects from
contributed code, taking what they like. HQ sells binary distributions, support,
applications, additional devtools, maybe a compiler. Runs a web-based community.
Runs an online marketplace for Rebol components --- objects / apps / whatever on
tap. In general HQ should focus on *value add* --- not just to the core language
but to the community as a whole. There's a whole business model.
> If they continue working on the development, then OpenSource
> efforts or idiosyncratic and obsolete?
>
Only if they duplicate API functionality the platform vendor has announced that
they're adding.
>
> As long as REBOL Tech continues developing REBOL, there is no possibility
> of adding functinality to REBOL as OpenSource projects?
>
I never said that.
>
> What you're saying is not making that much sense to me.
Clearly. ;-) Hope this message helped.
> Perhaps REBOL Tech
> would want to integrate OpenSource extensions into the official
> distribution?
Now there's a splendid idea.
>
>
> ;- Elan >> [: - )]
