[REBOL] Re: XML / dialects
From: jason:cunliffe:verizon at: 7-Jan-2002 12:58
<[SunandaDH--aol--com]> wrote:
> We need some additional mechanism to allow the secure sale of Rebol
> application code.
>
> That mechanism almost exists with Encap, so with a few tweaks, RT could
kick
> off a market rebolution.
oh, YES..
> Here's one way it could work.
>
> For some relatively small sum paid to RT (say USD10) I can activate the
> "encap-ability" of my otherwise freebie Rebol/View.
great idea
> That enables my Rebol/View to run "encapped" programs for which I hold a
key.
> So you (or anyone else) can sell me "encapped" code for whatever you want
to
> charge. If the price is right, and your code reputation is good and it's a
> tool I need, I'll buy.
>
> The only thing left is how do you "encap" your code? Well RT offer two
> mechanisms today. You could use a tweaked version of either of those. And
> here's a third that could help us small developers. We submit code to RT
for
> "encapping" and sale. If they like the code, they'll "encap" it and offer
it
> for paid-download from their site. They take a cut, the Rebol world gets a
> new tool, and you get some money from it!
That's a good idea for motivating and rewarding people who build significant
REBOL applications or tools.
A good example, I have been grappling with very recently: A web site
development has had its security compromised. From now on the site needs
secure client access tols such as SSH2 Telnet and better FTP.
What to do?
1. - Buy 3rd party commercial software such as those offered by F-Secure,
etc. F-
2. - Apply/Develop a REBOL-based solution. I'd much rather propose a
cross-platform REBOL tool. One which I am free to offer, at whatever price
and terms are appropriate. I believe people would not mind paying a small
amount of money ($5-$50) for a custom tool. Especially if that fee is
invisible, ie: factored into their basic service fee. And if it makes it
easy for authors distributors or end-users to upgrade transparently or via a
visible pay-per-XYZ scheme
A major advantage of REBOL and REBOL/View is that it _is_ cross platform. No
need to make people keep buying/installing when they switch
machines/locations.
In many file transfers, people are not really concerned about the data
itself. But they are very concerned about the CONTROL DATA [logins passwords
protocol acknowledgements etc].
Perhaps we need to think about a REBOL dialect for this aspect of 'secure
transactions'..?
This is the sort of thing design patterns folk spend a fair bit of time
thinking about, and XML-ers writing models of.
The key handles for this REBOL 'secure transactions' dialect might live in
the default header REBOL[], or perhaps use its own similarly styled header.
For example where we write now:
do %somefile.r
we might also write:
do/login
do/register
do/secure %somefile.r
do/tranaction %somefile.r
do/upgrade %somefile.r
do/pay paypal://%somefile.r
do/accept paypal://%somefile.r
do/billing %somefile.r
do/receipt %somefile.r
do/distribute %somefile.r
The point is to use REBOL's many strengths. To being a very pragmatic
platform which does not assume any e-platform dependency, but encourages a
higher level human-oriented approach. Gavin's post about XML raises a lot of
good points. But I also believe that ther are aspects which XML development
does not adderss adn indeed distracst designers adn prorgmraer from thinking
about. like ease-of-use ;-)
Assuming that XML or variations are here to stay globally, and that REBOL
gets better XML tools soon, I think it will still need REBOL-istic support
for transaction handling.
> Where's the downside?
For any of your ideas to work well, I think REBOL needs at least a standard
default tool + paradigm for propagating secure passwords and time-limited
keys. Something people can build upon. Some mechanism which can scale from
developer-to-developer all the way up to commercial shrink-wrapped REBOL
packages.
A downside would be anything which hinders open development and sharing as
REBOL community does now.
A downside is any scheme which depends too much on a centralized site for
handling. REBOL is aimed at non-centralized "x-internet" architectures.
As you point sorely lacks a few key elements to allow and encourage easy
commercial distribution.
./Jason
