|is interpreted nature of rebol an obstacle to developing commercial app|
|is the interpreted nature of rebol a problem for commercialising an application made with Rebol?|
I would like to find out, if anyone among members here, has done any commercial application with Rebol ?
So do you have to package your source and give it out to your client ? 1) are you not afraid that someone will just copy your code and then create a competing product ? 2) since the code is available to your client, what about if your client, add new features or modifies the application by himself without your knowledge, this will be a loss of revenue to you. (I have personal experience of this in one of my previous jobs)
I prefer RED's approach, which compiles,in this way your code is not disclosed that easy.
Mind you I understand that you can even reverse engineer a compiled object, but not many people would have time or would want to do this. How many times have i reverse engineered or decompiled a third party java program. Only 2 times in my whole career, and it was messy and it's something I am very leery about doing again...
let me have your thoughts.
|hum wet_wet_wet does interpret nature of php made it unknown, irrelevant and hobistic programing language like rebol is?|
wet_wet_wet according to RMA and cyphre they make a ton of monney selling rebol applications.
|It is the goal of encap to avoid selling the sources and the VM : the source are encapped in the VM, like sources of Rebol itself are (ie: the rebol desktop, or the editor).|
So you sell a program like you does it it was compiled.
At this time, r3 does not encapped source code. But it's steel in alpha stage and many things need to be done before it reached r2 functionnality.
r3 does also include the module concept. And AFAIK modules can be (will be ?) even crypted .
|Thanks for your comments.|
@didec - from encap information on the site, does not really compile, it looks more a compressed executable, where you bundle your source and the rebol interpreter in a compressed, encrypted self extracting executable.
it's just like what you can do with winrar or winzip.
to execute your program, the code needs to still be unzipped, (and become visible)
this is what we did in the previous place where I worked some years back. We created self executable zip files,and yet the client was able to intercept the code and get his own in house programmer to make changes himself, thus causing loss of revenue to my employer. we caught them only when something went wrong, and they called us for help. We were using an interpreted language (in the top 15 language list on the TIOBE site).
this experience has taught me a lesson. Interpreted languages are good only for internal use or self hosting apps or web or AAS(app as a service) but not for apps you have to sell directly to clients and run on their machines.
I am more interested in something truly compiled, where source code is turned into machine code. (i.e true compilation like C, C++, PASCAL languages) which makes it relatively more difficult for someone to steal or hack your code.
|Rebol can not be compiled. Period.|
This has been discussed on many channels by advanced users, no need to do it again here.
Encap do more that what you think.
Because the source code is not extracted on the disk like with some kind of Archive. It is in some way in memory, but just to be loaded by the VM. Then, only the objects code stay in memory.
If you find a way to extract the source code of the current Rebol2 VM (Rebol code I mean), before it ends loading, tell me how.
If you can't, so it will be with your apps code
|am aware it cannot be compiled, and am not trying to question whether it can be compiled. we have RED for that. |
was just trying to gauge how to make use of REBOL from a commercial application development point of view, hence the question to the community here.
My main interest is to find out how rebol applications are being sold commercially and how are people doing it w.r.t to the source code packaging and how is Rebol being used today by the community here ?
with all due respect to carl's encap approach, I believe it is not a good solution, to decompress, decrypt every time before it feeds into the interpreter (not VM) ,it will slow down the application. Rebol is already slow.
so far the only few ways I can think of using Rebol (without the risk of people nicking the code) is for inhouse application only or web based hosted on our own server. maybe I am wrong and there are other ways, hence my initial question.
the truth is that I have not played with REBOL that long, as indicated by all the posts on this site. I actually dumped it a few months after starting playing with it for the reasons mentioned in other posts on this site.
Since now the situation has changed, I am re-assessing the viability...
|best way is the php approach you use a rebol web solution to rendre web pages and retrieve data that way your code is no shown to the world.|
Login required to Post.