Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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
> 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
> So you (or anyone else) can sell me "encapped" code for whatever you want
> 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
> "encapping" and sale. If they like the code, they'll "encap" it and offer
> 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