<[EMAIL PROTECTED]> 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
