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

Commercializing Rebol

 [1/27] from: robert:muench:robertmuench at: 15-May-2001 10:41


Hi, I'm currently developing a concept for a new business, which most likely will be based on Rebol. Anyway, I have some points I'm not sure how these are/can be handled (if at all): 1. Runtime Version ================== - Is it possible to update the script included in a runtimed Rebol application? I think one of Rebol's nice features is that it's possible to distribute applications via the Reb. The client should be able to identify to a /Express server and receive an encrypted Rebol script (update) in response. IMO this feature is not needed to hide the script from users but to build up trust between user and provider. Will you trust a Rebol script, you don't know where it comes from? - Can the Rebol engine be updated automatically? 2. Data storage =============== I have been thinking about this for quite some time now. I'm not sure if it will be possible to create 'big' business applications without using a database. If a database is needed, than how do we sync this with the client? Is the database needed on the client too? How do we install the DB, etc.? Replicating databases is something I don't like. Rebol/Express has a nice syncing feature for all kind of files. Will this concept be able to handle databases too? I don't think so (yet). How do we handle database schema changes? Will it be possible just to use plain files for all kind of data? Depends on the data-size. Currently Rebol is reading in all the data from a file. What about 500 MB of data? Reading it sliced in pieces? How to search etc. IMO this is a basic problem if you want to use Rebol for business applications. At the moment we have to handle the problem like in all other languages. 3. Constraints ============== We had this topic in an other thread already. But still IMO this would be a very nice feature. Maybe it's already possible? [If so please let me know :-)]. With such a concept included into Rebol (not only for GUI stuff), development time could be radically cut for quite a lot of applications. What do you think? Robert

 [2/27] from: petr:krenzelok:trz:cz at: 15-May-2001 12:10


Robert M. Muench wrote:
> Hi, I'm currently developing a concept for a new business, which most likely > will be based on Rebol. Anyway, I have some points I'm not sure how these
<<quoted lines omitted: 7>>
> to build up trust between user and provider. Will you trust a Rebol script, > you don't know where it comes from?
I would also like more in-depth description of what is being possible with run time. One thought came to my mind once I read Richard's comment upon upcoming SWIS features - sound - for those having Pro licence key. But - features are already inside, what about following scenario: Those of us having run-time and Pro licence key bought, would be able to generate some kind of object code. Others (not having Pro licence key) would be still able to run the code, although not to view its source, nor to use features in interpreter level, which are locked.
> - Can the Rebol engine be updated automatically? >
dynamic components would be nice for that - is there new sound one? download it, while core remains the same ... however, you can upgrade rebol, no? Express does so - the problem is Windows locks file it is running, so you have to find workaround ...
> 2. Data storage > > I have been thinking about this for quite some time now. I'm not sure if it > will be possible to create 'big' business applications without using a > database. If a database is needed, than how do we sync this with the client? > Is the database needed on the client too? How do we install the DB, etc.?
no installation procedures (registry dependency) if possible, please ... We are still using old good Xbase4 format, supported by Visual Objects, Clipper, Delphi, Visual Basic, FoxPro - .dbf files, .cdx multitag indexes and .fpt memo files. It is powerfull enough for many purposes and there is many externall tools out there, which allow you to view and maintain data ...
> Replicating databases is something I don't like.
I agree ...
> Rebol/Express has a nice > syncing feature for all kind of files. Will this concept be able to handle > databases too? I don't think so (yet).
Not sure, but, as for me, I like async systems personally. If you have some data to store into db, or various dbs, you just send/store "message", being it xml based or in other format. DB or other machine waits in certain place (port or some dedicated spool directory) till something appears and does a job. Of course roll back mechanisms (transaction) would be cool too, but it is probably too high wish :-)
> How do we handle database schema > changes? > > Will it be possible just to use plain files for all kind of data?
In no way imo .... You can use filesystem to store data as Elan doe in his User's Guide, but I am not sure if it is not a little bit resource hungry ...
> Depends on > the data-size. Currently Rebol is reading in all the data from a file. What > about 500 MB of data?
Well, in one of messages sent to list Holger described one of port types (not currently available) which will allow some functionality allowing you to write db driver - it is plain nonsense to load 500MB data into memory :-) It is also long time ago I suggested to adapt parser to work upon openend ports. Carl replied in sense it would be cool to have, but RT has probably more important issues to solve. Parse working only upon cached data (data read into memory) is pretty much limitation once working with large data files. My mailbox is some 70 MB text file now :-) ... I think it would be really neat to have!
> Reading it sliced in pieces? How to search etc.
As I said above - we currently have parser - why to complicate things? Let it work upon opened port. Being it one way or other - most parse operations are just buffer skips, so what? At least some parse functionality could be supported that way imo ...
> IMO this is a basic problem if you want to use Rebol for business > applications. At the moment we have to handle the problem like in all other
<<quoted lines omitted: 4>>
> :-)]. With such a concept included into Rebol (not only for GUI stuff), > development time could be radically cut for quite a lot of applications.
I don't understand what "constraint programming" means. Do you have any link to any interesting articles? Would appreciate :-) Thanks, -pekr-

 [3/27] from: brett:codeconscious at: 15-May-2001 20:16


Hi Robert, Just want to make comment about the data.. comments interleaved....
> 2. Data storage > > I have been thinking about this for quite some time now.
I've given this some thought as well - though it was in the context of a specific application. Without knowing your specific requirements my comments can only be general (phew :) ).
> I'm not sure if it > will be possible to create 'big' business applications without using a > database. If a database is needed, than how do we sync this with the
client? I believe 'big' business applications usually have a database because it stores the data (usually) in one place thus making the job of managing/querying business-wide data easier. Apparently Rebol/Express can talk to a database so Rebol/Express can act as an application server and talk to the database on behalf of the client. The client no longers talks to the database so the problem of syncing client with database becomes irrelevent. Interestingly this solution solves two problems created by the client-server (2 tier) "solution". It increases security of the database and decreases deployment problems of client-side database drivers.
> Is the database needed on the client too? How do we install the DB, etc.? > > Replicating databases is something I don't like. Rebol/Express has a nice > syncing feature for all kind of files. Will this concept be able to handle > databases too? I don't think so (yet). How do we handle database schema > changes? >
I don't know if the question is so important because I'm sceptical about clients needing a full client-side database. I know embedded databases exist but I suspect that their existence is a lot to do with the existence of database manipulation controls of RAD tools. A number of people have proposed using XML as a local store of data on the client - and thus we see an evolution of the focus in RAD tools to encompass XML as a local store. Given we are talking about Rebol here. The local store is Rebol or more likely a custom dialect. The custom dialect could enforce some integrity constraints merely by enforcing certain ordering rules in the grammar. These can be checked again on submission to the Express application.
> Will it be possible just to use plain files for all kind of data? Depends
on
> the data-size. Currently Rebol is reading in all the data from a file.
What
> about 500 MB of data? Reading it sliced in pieces? How to search etc.
I guess there might be data that plain files might not be suitable for, but I think a "plain" file that is a text file with data structured in a dialect could handle a lot of situations. Yes data size could be an issue but it really depends on your application. How much data do you *really* need on the client at all times for users of your application to be able to achieve their objectives? You didn't mention security. With Rebol the local data could be encrypted for security. Some embedded databases might do this but then again how many do? And XML. What out-of-the-box tools can be embedded into a client side application to encrypt local XML stores of data? No doubt people are solving this problem but just thought I'd throw up the "Beware of Nasty Thing" sign. :)
> IMO this is a basic problem if you want to use Rebol for business > applications. At the moment we have to handle the problem like in all
other
> languages. >
I agree and respectfully disagree. I believe Rebol looks at the world differently from how other languages look at the world. Therefore to get the most out of Rebol one should take the Rebol point of view and structure a solution accordingly. I think a big trap is to emulate using Rebol a solution structure that accommodates by design the strengths and weaknesses of another technology. (I hope that makes sense - I had to re-read it twice...) So yes Rebol may be difficult if one tries to solve the problem in the same way that one would with other languages, but I suggest there is no difficulty at all if one steps back and asks "how does Rebol solve this problem elegantly?" I suggest pulling out the old Data Flow Diagrams again (with Rebol they gain new value) and looking hard at what goes where and why. Thanks for initiating an important discussion. Brett.

 [4/27] from: rgaither:triad:rr at: 15-May-2001 8:09


>2. Data storage >>I have been thinking about this for quite some time now. I'm not sure if it >will be possible to create 'big' business applications without using a >database. If a database is needed, than how do we sync this with the client? >Is the database needed on the client too? How do we install the DB, etc.?
The only time you want a database on the client as well is to support an "offline" mode or possible performance considerations. In most big business setups it is better to put the effort into having the database available all the time at a central location than deal with replication or special client setups. Brett makes several good points about this topic as well. The need to think about the problem differently is very important as well as very hard. I have been dreaming of a binary XML based database that adds features like indexing and queries for that local data store example.
>IMO this is a basic problem if you want to use Rebol for business >applications. At the moment we have to handle the problem like in all other >languages.
Yes it is. Storage is one of REBOL's weak spots - with the exception of the simple needs that load and save handle. This is not a slam on REBOL though as even the huge companies with monster distributed OOP architectures go for the hybrid approach of objects being mangled to fit into a RDBMS for storage. That same hybrid approach works in REBOL today. It would be great if we found/created a better option. :-) FWIW, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [5/27] from: robert:muench:robertmuench at: 15-May-2001 17:43


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 4>>
> Without knowing your specific requirements my comments can only be general > (phew :) ).
Hi, no problem. I'm seeking for a broad general approach to solve the problem.
> I believe 'big' business applications usually have a database because it > stores the data (usually) in one place thus making the job of > managing/querying business-wide data easier.
And that's the big disadvantage today. More and more people are becoming mobile, you don't have a fixed office/cubicle anymore, you move around and you need your data. Internet access in the fields is still slow and I can't work online for the whole day, at least not in Europe.
> Apparently Rebol/Express can talk to a database so Rebol/Express > can act as an application server and talk to the database on behalf of the > client.
That's how every application is done today. So far OK.
> client no longers talks to the database so the problem of syncing client > with database becomes irrelevent.
But I don't have access to my data if I can't access the server...
> I don't know if the question is so important because I'm sceptical about > clients needing a full client-side database.
Well, here we disagree. I see the FAT (storage) client as the solution. The central server will store all data (VERY FAT server) and my client will have my personal view and data extensions on it. Unfortunately the amount of data increases tremendously. I'm working as a management consultant, each client project needs about 250 MB of space. I'm using a personla knowledge-base, which is about 2GB in size... and yes, I really need all this stuff.
> Given we are talking about Rebol here. The local store is Rebol or more > likely a custom dialect. The custom dialect could > enforce some integrity constraints merely by enforcing certain ordering > rules in the grammar. These can be checked again > on submission to the Express application.
I agree. And I'm searching for the Rebol way to do it... I don't like the idea to fallback to a DBMS system to handle data on the client. But as soon as a lot of data > 100 MB needs to be handled, fast searching is a must, etc. I don't see another way.
> I guess there might be data that plain files might not be > suitable for, but > I think a "plain" file that is a text file with data structured > in a dialect could handle a lot of situations.
Hmm... I don't know if it's possible but a self-indexed plain file, which uses /Rebol functionality to index the file might be cool. Example: We have a file storing objects, and the object has direct links to releated objects. We could just read in an object from file and would get the next(), prev() code with it. Now just call next() and the code to access the next object will be executed. This is a rolled out index, but how to update it?
> How much data do you *really* need on > the client at all times for users of your application to be able > to achieve their objectives?
A lot! Take my knowledge-base, I would like to do a Rebol front-end for it, of course I want to have my complete knowledge-base, not just a part of it.
> You didn't mention security.
I thought it was enough I mentioned ;-)
> With Rebol the local data could be encrypted > for security. Some embedded databases might do this but then > again how many > do? And XML. What out-of-the-box tools can be embedded into a client side > application to encrypt local XML stores of data?
Right, I hope it is fast enough to handle all the amounts of data...
> Therefore to get the > most out of Rebol one should take the Rebol point of view and structure a > solution accordingly.
Right! And that's what I try to do but I didn't came up with THE solution (yet). Robert

 [6/27] from: robert:muench:robertmuench at: 15-May-2001 17:43


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 4>>
> The only time you want a database on the client as well is to support > an "offline" mode or possible performance considerations.
Hi, right and especially the "offline" mode is very important.
> In most big > business setups it is better to put the effort into having the database > available all the time at a central location than deal with replication or > special client setups.
Agreed, if it's possible. As consultant I don't have a classical "home-base" to referr to. I need my stuff where I am...
> I have been dreaming of a binary XML based database that adds features > like indexing and queries for that local data store example.
:-)) Yes that would be nice. Robert

 [7/27] from: robert:muench:robertmuench at: 15-May-2001 17:43


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On
<<quoted lines omitted: 5>>
> so - the problem is Windows locks file it is running, so you have to find > workaround ...
Hi, I see the problem in updating a /Runtime version. How do you update the script of a /Runtime version without killing the /Runtime engine and how do you update the /Runtime engine without killing the encrypted script contained in it? Will the client have to download a complete new EXE? Than I have to handle the process of generating a /Runtime version for the client... not very cost effective.
> As I said above - we currently have parser - why to complicate > things? Let it work upon opened port. Being it one way or other - most
parse
> operations are just buffer skips, so what? At least some parse
functionality
> could be supported that way imo ...
Hmm... I'm not sure if parse on opened port will solve the problem. Accessing huge amounts of data fast needs some datastructure infrastructure ;-) to be efficient & effective. If you want to use parse, than parse would have to support several channels: One data channel to skip along; one index channel, which will provide optimized skip information for the data channel etc.
> I don't understand what "constraint programming" means. Do you > have any link to any interesting articles? Would appreciate :-)
Try the www.mozart-oz.org and www.openip.org the OpenAmulet documentation contains some information about constraint programming. Hope this helps. Robert

 [8/27] from: jseq:mediaone at: 15-May-2001 12:36


>> I have been dreaming of a binary XML based database that adds features >> like indexing and queries for that local data store example. >
And here's another one I thought of: http://www.equi4.com/metakit/ No synchronization framework that I know of, but still hugely cross platform w/C++ API. Probably lighter-weight and cheaper. The above web site has a number of projects that are similar in spirit to what you're describing. The term they're using is scripted documents, which I think captures at least one aspect LDC pretty well. They've taken Tcl/Tk along this road, and developed a persistence engine (MetaKit) to support more involved applications -> the domain where Rebol (or at least Rebol developers) now seek to tread. Again, no personal experience so YMMV. js [johnseq--pobox--com] http://www.pobox.com/~johnseq

 [9/27] from: jseq:mediaone at: 15-May-2001 12:24


>> I have been dreaming of a binary XML based database that adds features >> like indexing and queries for that local data store example. >
This sounds a lot like the BirdStep Database engine. Small footprint, runs on huge # of platforms (incl. PDA/*nix/Win32), supports hierarchical/XML and relational views, available synchronization framework. http://www.birdstep.com/products/bdbe.php3 I have no experience with it except for reading the web site, but damn it'd be cool to interface this with REBOL. John Sequeira [johnseq--pobox--com] http://www.pobox.com/~johnseq

 [10/27] from: rgaither:triad:rr at: 15-May-2001 13:22


Hi John,
>This sounds a lot like the BirdStep Database engine. Small footprint, runs on huge # of platforms (incl. PDA/
*nix/Win32), supports hierarchical/XML and relational views,
>available synchronization framework. > >http://www.birdstep.com/products/bdbe.php3 > >I have no experience with it except for reading the web site, but damn it'd be cool to interface this with REBOL.
I have checked this one out before - very interesting indeed. Having a bit of trouble figuring out the cost though. :-) A few others that look or looked interesting - http://www.dbxml.org/ http://www.xmldb.org/ http://www-db.stanford.edu/lore/home/index.html http://www.softwareag.com/tamino/ http://www.openlinksw.com/virtuoso/ FYI, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [11/27] from: petr:krenzelok:trz:cz at: 15-May-2001 19:45


----- Original Message ----- From: "Robert M. Muench" <[robert--muench--robertmuench--de]> To: <[rebol-list--rebol--com]> Sent: Tuesday, May 15, 2001 5:43 PM Subject: [REBOL] Re: Commercializing Rebol
> > -----Original Message----- > > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 3>>
> > Subject: [REBOL] Re: Commercializing Rebol > > Without knowing your specific requirements my comments can only be
general
> > (phew :) ). > Hi, no problem. I'm seeking for a broad general approach to solve the
<<quoted lines omitted: 5>>
> mobile, you don't have a fixed office/cubicle anymore, you move around and > you need your data. Internet access in the fields is still slow and I
can't
> work online for the whole day, at least not in Europe.
then you need powerfull replication mechanism .... I think most of what you discuss is solved by Express - dialect based protocol communication in app level, synchronisation to local machine to allow you to work even off-line ...
> > Apparently Rebol/Express can talk to a database so Rebol/Express > > can act as an application server and talk to the database on behalf of
the
> > client. > > That's how every application is done today. So far OK. > > > client no longers talks to the database so the problem of syncing client > > with database becomes irrelevent. > > But I don't have access to my data if I can't access the server...
What is data for you then? Is there any other way? If you need some really powerfull db solution, you probably use Oracle, DB2 or similar server-side solution. IF you need your data to be available off-line, you would have to create mechanism of being able to select what kind of data to replicate. We use Lotus Notes groupware here and you can choose, which database and when is replicated. It's kind of incremental replication (even /Express does that), so ppl just press button before they go off-line and selected databases are replicated to their replicas on local machine, mostly notebooks. Then it is app to app logic (just my guess as I don't programm in LN dev. environment) to use local stored data ...
> > > I don't know if the question is so important because I'm sceptical
about
> > clients needing a full client-side database. > > Well, here we disagree. I see the FAT (storage) client as the solution.
The
> central server will store all data (VERY FAT server) and my client will
have
> my personal view and data extensions on it. Unfortunately the amount of
data
> increases tremendously. I'm working as a management consultant, each
client
> project needs about 250 MB of space.
ouch, that's pretty high number :-)
> I'm using a personla knowledge-base, > which is about 2GB in size... and yes, I really need all this stuff.
2GB of data locally? Hmm, I am not sure if it is efficient to solve it via some local mechanism. What about running db server on your machine then? Or do you have any concrete mechanism in mind?
> > > Given we are talking about Rebol here. The local store is Rebol or
more
> > likely a custom dialect. The custom dialect could > > enforce some integrity constraints merely by enforcing certain ordering > > rules in the grammar. These can be checked again > > on submission to the Express application. > > I agree. And I'm searching for the Rebol way to do it... I don't like the > idea to fallback to a DBMS system to handle data on the client.
But it will allow you to abstract the solution - still the same app, just switch to local store. On the other hand off-line idea is a little bit flawed imo. The future is (although I can't know how near future I am talking about :-) to be ALWAYS connected! It means - you can always replicate your data - it should not take so much time to do synchronisation with your central DB. I am also not sure if there is any general aproach. Look at /Link - it downloads it's conference messages to client, but I can also imagine some areas where you would not like to do so ...
> > I guess there might be data that plain files might not be > > suitable for, but > > I think a "plain" file that is a text file with data structured > > in a dialect could handle a lot of situations. > > Hmm... I don't know if it's possible but a self-indexed plain file, which > uses /Rebol functionality to index the file might be cool. Example: We
have
> a file storing objects, and the object has direct links to releated
objects.
> We could just read in an object from file and would get the next(), prev() > code with it. Now just call next() and the code to access the next object > will be executed. This is a rolled out index, but how to update it?
I don't want to be negative, but we are probably going to reinvent the wheel. If you need power, let your data be handled by really powerfull solution. What about several instances of the same app running on your local system? Are you prepared to solve concurency system in your solution? And what about transactions? System without transactions can turn into wery painfull experience. I know that! Never more for really important data - you need rollback methods implemented etc. etc. I am not sure there is simple and general aproach of how to solve the situation ... probably the best one is interfacing to existing db systems ... And you can bet that I would too like to see some very elegant, lightweight, Rebol based solution to the problem ... :-) regards, -pekr-

 [12/27] from: petr:krenzelok:trz:cz at: 15-May-2001 20:01


----- Original Message ----- From: "John Sequeira" <[jseq--mediaone--net]> To: <[rebol-list--rebol--com]> Sent: Tuesday, May 15, 2001 6:24 PM Subject: [REBOL] Re: Commercializing Rebol
> > > >> I have been dreaming of a binary XML based database that adds features > >> like indexing and queries for that local data store example. > > > > This sounds a lot like the BirdStep Database engine. Small footprint,
runs on huge # of platforms (incl. PDA/*nix/Win32), supports hierarchical/XML and relational views,
> available synchronization framework. > > http://www.birdstep.com/products/bdbe.php3
And another one, which was ported to QNX RtP: http://www.sleepycat.com/ -pekr-

 [13/27] from: gjones05:mail:orion at: 15-May-2001 15:35


From: "John Sequeira"
> And here's another one I thought of: > http://www.equi4.com/metakit/
<<quoted lines omitted: 9>>
> Rebol developers) now seek to tread. > Again, no personal experience so YMMV.
I have played with TclKit, which is the Tcl-binding version of MetaKit. The creator, Jean-Claude Wippler, has really done some serious thinking on the problems of distibution, especially of distributing scripting language solutions. The documents bear reading, if for no other reason than for its "brain food" value. The problem with the site is that much of the interesting reading is buried in a wiki. The one other document that specifically covers the idea of a scripted document is located at: http://www.equi4.com/jcw/wiki.cgi/18.html There are some other interesting, thoughtful documents at this site, but I seem unable to re-find them (one of the problems with some wikis). What I am unsure about, is how this specific solution would be melded with REBOL, and whether the lack of MetaKit database scalability would prove too much of a hindrance for larger tasks and/or multi-user access. The concept is solid, in my opinion, and would be the sort of solution I would like to see for REBOL applications meant for distribution to the general public (meaning, less than truly computer-competent). The REBOL runtime (and runtimes yet to be) apparently achieves some of these goals. An expanded wrapper-type solution including database would be ideal. Thanks for the post that has stimulated so much interesting discussion. --Scott Jones

 [14/27] from: brett:codeconscious at: 16-May-2001 10:51


Hi Robert, I see that we were talking from two completely different 'big' business worlds. My context was with more transactional type systems, yours appears to be more a document management problem. I can see a bit clearer now why you are pushing for local databases. You have this huge lump of data that cannot be deconstructed into smaller databases because you do ad-hoc querying over it. I'm somewhat unsure what you perceive as Rebol's "value add" in this situation. What is it that you perceive Rebol is going to do for you better than something else? Brett.

 [15/27] from: gjones05:mail:orion at: 16-May-2001 6:07


From: "Robert M. Muench"
> I like the wrapper idea, too. It's really nice to be able to pack
everything you
> need into one EXE file. I hope RT will expand this idea further. Since
HD space
> is so cheap I really don't like the shared-library concept anymore.
How many
> time have you lost because of problems with shared files, wrong
versions etc.?
> Just compile everything into one file and that's it. I prefer to waste
some
> space on my HD than time. Robert
Here, Here! That is the voice of sanity speaking. I would cast my vote that way for sure. --Scott Jones

 [16/27] from: petr:krenzelok:trz:cz at: 16-May-2001 13:46


Robert M. Muench wrote:
> > -----Original Message----- > > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 14>>
> need into one EXE file. I hope RT will expand this idea further. Since HD space > is so cheap I really don't like the shared-library concept anymore.
But wait a minute - who speaks of shared libraries? Besides that - if you prefer bloat in principle, it says someting. It has nothing to do with HD space. But - mobile communication is coming. There is no space to waste. Mobile networks are also throughput limited - how do you upgrade your component if everything is internally inside one .exe? Let's say Carl changes something in VID and I really don't understand why should I download the whole Rebol once again. Rebol, in its principle, - is very granular (referring to series). If you don't like your files scattered around your harddisk, probably some looong time ago suggested aproach could work, but I am not sure - maybe rebol could have some 'pack 'unpack commands, which would attach components into the executable. But then having .zip allowing us to work inside of .zip archive as with default directory would be probably more efficient - you can just use plenty of file managers (not stupid Windows Explorrer) to enter such files and treat them as being directories - then you can "pack" your desired functionality (whole directory structures) inside (but maybe speed would be the problem here) ... But maybe you mean just something different? e.g. mechanism working as linker, which would pack functionality needed into one executable, so if DLL contains e.g. 10 funcs and only 3 of them are called, then those 3 would be linked in? Or?
> How many > time have you lost because of problems with shared files, wrong versions etc.? > Just compile everything into one file
You can as well have your librarie in the same directory as app is, so what version problems are you talking about? Remember - we are not talking system libraries and its dependencies here, right? So if you are author of an app, and you KNOW your clients will need new library, just put REBOL [ Author: "Robert Muench" Needs: [ file: %my-lib.dll version: 3.0 home: http://www.robertmuench.de/projects/companyXY/appZ/my-lib.dll ] ... it would not be problem for RT to create such support mechanisms imo .... or you can always check for the right version to be in-place and download it if not present .... There is many possibilities, -pekr-

 [17/27] from: rgaither:triad:rr at: 16-May-2001 7:57


>> Having a bit of trouble figuring out the cost though. :-) > >?? Why this ?? Did you contact them?
No - part of the problem. I generally subscribe to the philosophy that if the price isn't listed it is going to be high. Too much for the kind of personal data store I would like to have.
>> http://www.softwareag.com/tamino/ > >This one I know a bit, it was evaluated by a team I know. They >were very impressed by Tamino's power etc. but seems to be quite >expesnive.
Thanks for the info. I did get pricing info on Tamino and it was too high as well. :-) Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [18/27] from: gjones05:mail:orion at: 16-May-2001 9:00


> > > GS Jones
GSJ> > > The concept is solid, in my opinion, and would be GSJ> > > the sort of solution I would like to see for REBOL GSJ> > > applications meant for distribution to the GSJ> > > general public (meaning, less than truly computer-competent).
> "Robert M. Muench" wrote:
RMM> > Hi, maybe someone from RT can have a look at it, for RT it RMM> > should be a no-brainer to create the right solution ;-)). GSJ> > > The REBOL runtime (and runtimes yet to be) GSJ> > > apparently achieves some of these goals. An expanded GSJ> > > wrapper-type solution including database would be GSJ> > > ideal. RMM> > I like the wrapper idea, too. It's really nice to be able RMM> > to pack everything you need into one EXE file. I hope RMM> > RT will expand this idea further. Since HD space is so RMM> > cheap I really don't like the shared-library concept anymore. From: "Petr Krenzelok" <[Petr--Krenzelok--trz--cz]> PK> But - mobile communication is coming. There is no space to PK> waste. Mobile networks are also throughput limited - how do PK> you upgrade your component if everything is internally inside PK> one .exe? Let's say Carl changes something in VID and I really PK> don't understand why should I download the whole Rebol once PK> again. Rebol, in its principle, - is very granular (referring to series).
<snip>
PK> But maybe you mean just something different? e.g. mechanism PK> working as linker, which would pack functionality needed into PK> one executable, so if DLL contains e.g. 10 funcs and only 3 PK> of them are called, then those 3 would be linked in? Actually, I am envisioning a different mechanism, and here is where I wish I could find the additional reference links from Jean-Claude Wippler's site. The TclKit-MetaKit combination actually uses the MetaKit database to store the components of the distribution. If I recall correctly, Jean-Claude's vision was that the scripted document could allow for either a simple, whole replacement (executable file for executable file without the need for any real installation, per se), or that components in the database could be updated through a network! Here is where the beauty and the power seems to lie in the concept as I understand it. So basically, Petr, the additional things you wrote about (not herein included) basically foreshadow the idea I'm trying to present, that such a system exists, at least at a rudimentary level. The added beauty, as I made reference to, is that the MetaKit implementation "automatically" compresses all stored files, and, furthrmore, this compressed version is binary compatible (at least the data elements; obviously a platform specific library would not work on the incorrect platform). I believe you are still entirely correct by pointing out that shared resources were designed in part to reduce redundancy in storage. My vision of the extension of Jean-Claude's vision of the scripted document does not entirely avoid this pitfall. It at least optimizes on the problem through compression. A typical Tcl/Tk basic working model (not developmental model) might span several megabytes, but the TclKit compressed version is about 750KB. Like the REBOL executable interpretor, it expands in memory as a part of the process of being run. A REBOL distribution so encapsulated would be even smaller. With Regards, --Scott Jones

 [19/27] from: kenneth:nwinet at: 16-May-2001 7:32


Just to add my two cents. When I'm working on something, I want all the pieces exposed and layed out in front of me. When I give it to my customer, I want it in one package. I will worry about size and how to update. While in principle, incremental updates are a neat idea, in practice it just leads to job security in the support department. I personally know one guy that supports hundreds of his customers easily all by himself; whereas, less than 50:1 is common supporting the package I work with these days. Much of this support cost is due to components being overwritten on the customers systems (often o/s components which I think we should all charge back to Mickysoft.) Ken.

 [20/27] from: gjones05:mail:orion at: 16-May-2001 10:15


From: "Ken Anthony"
<snip> > When I'm working on something, I want all the pieces exposed and layed
out
> in front of me. > > When I give it to my customer, I want it in one package. <snip>
And this is precisely how the TclKit-MetaKit combination works. Your development files are laid out as you like them, but the TclKit scripting document creator program combines them into a single, executable file. The components are reached through the database system. The end user only sees and deals with the one file in a typical scenario (as always, there is a little more to the story...). It is the concept on which I am focusing, and the concept seems very neat. It also seems "doable" in REBOL, at least in principle. Problems remain; this solution is hardly a panacea. KA> I will worry about size and how to update. While in principle, incremental KA> updates are a neat idea, in practice it just leads to job security in the KA> support department. Oh, so true. Just supporting my wife's cobbled together eBay and website management scripts is more work than I care for it to be, but I believe that a scripted document-type approach would be easier in our case. As an aside, one might ask why not just use Tcl/Tk and the aforementioned package. I was going to, but I have this mental block on the Tk model for a gui. I just never got up to speed in Tk, certainly in comparison to /View VID. This single, "scripted document" arrangement is a very compelling concept to me, putting aside, for the moment, Petr K's well founded and easily understood concerns. I have additional and, as yet, unexpressed concerns and reservations. One is the idea that any data is ever encoded in a non-directly readable format. Legacy problems become built-in, and this seems to be a bad design choice make from the very outset! I take some consolation that the solution mentioned is open source, and that the binary is cross-platform compatible without need for translation of endians, etc. I guess I always want my cake and to eat it too. I want the information to be stored in a human-readable format and yet quickly addressable and compressed! --Scott Jones

 [21/27] from: robert:muench:robertmuench at: 16-May-2001 17:19


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 4>>
> I see that we were talking from two completely different 'big' business > worlds.
Hi Brett, I should have been more precise on what I mean... Communication problems are the hardest ones to solve.
> My context was with more transactional type systems, yours appears > to be more a document management problem. I can see a bit clearer now why > you are pushing for local databases.
Right. I don't see Rebol in the transactional area and I agree with you that it doesn't make sense to run transactional systems on user systems, therefor we have the client/server concept.
> You have this huge lump of data that cannot be deconstructed into smaller > databases because you do ad-hoc querying over it.
Absolutely right.
> I'm somewhat unsure what > you perceive as Rebol's "value add" in this situation. What is it that you > perceive Rebol is going to do for you better than something else?
Ok, now we come to the point ;-). The problem with this lump of data is that it's mostly unstructured (or better has no implicit relationship). I know the releationship but I can't write it down in a way a program can use it to help me. Than I have several processes, workflows, etc. which are related to information, todos etc. In short: Goals, tasks and information should be integrated. I would like to use Rebol as the front-end for such an application and therefore I need a database too. Robert

 [22/27] from: robert:muench:robertmuench at: 16-May-2001 17:19


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 4>>
> But wait a minute - who speaks of shared libraries? Besides that - if > you prefer "bloat" in principle, it says someting.
Hi, that's ture ;-).
> It has nothing to do with HD space. But - > mobile communication is coming. There is no space to waste. Mobile > networks are also throughput limited - how do you upgrade your component if
everything
> is internally inside one .exe?
The point is right, and now you know why I asked how can I update a /Runtime wrapped script without having to download the whole /Core again. I see the wrapping method as a shelter for my application, more like a delivery container no one can touch, it's my application's universe.
> Let's say Carl changes something in VID and I really don't > understand why should I download the whole Rebol once again. Rebol, in its > principle, - is very granular (referring to series).
Right, and that's why Rebol should support a selective update function for wrapped parts. But I don't care to download 600KB for a new application if it has everything contained. If this safes me 30 minutes of work, because the app just works it's good! I don't like downloading Rebol than an app, than an update to Rebol and the app doesn't work anymore... This is OK as long as we have short scripts but not with professional applications.
> If you don't like your files scattered around your harddisk, probably > some looong time ago suggested aproach could work, but I am not sure - maybe > rebol could have some 'pack 'unpack commands, which would attach components
into the
> executable.
Here we are on the right track IMO.
> But maybe you mean just something different? e.g. mechanism working > as linker, which would pack functionality needed into one executable, so if
DLL
> contains e.g. 10 funcs and only 3 of them are called, then those 3 would be
linked in? Or? This would be nice but it's hard to achive, with non object code. I don't think it will be possible.
> You can as well have your librarie in the same directory as app is, > so what version problems are you talking about?
;-) Well, and than I prefer a single file because libraries in the same directory as the app is just a tautology. However, if you want to install two versions, you need two directories... Robert

 [23/27] from: petr:krenzelok:trz:cz at: 16-May-2001 22:21


----- Original Message ----- From: "Ken Anthony" <[kenneth--nwinet--com]> To: <[rebol-list--rebol--com]> Sent: Wednesday, May 16, 2001 4:32 PM Subject: [REBOL] Re: Commercializing Rebol
> Just to add my two cents. > > When I'm working on something, I want all the pieces exposed and layed out > in front of me. > > When I give it to my customer, I want it in one package. > > I will worry about size and how to update. While in principle,
incremental
> updates are a neat idea, in practice it just leads to job security in the > support department.
not always, sorry. We built our own mechanism here, keeping them very simple. One of my requirements I asked my friends to keep in mind was total independency of Windows registry. While I come to opinion conflict with some other programmers, Win registry is one of the most piggy things about OS. All we do is just - copy and run, and that's important for us. As for our mechanism - we created cetral database of users, and each user has his own .ini file containing his identify info. We can easily let choose all users, certain users, some of departments to sync new files, choose file locations, or let them do complete resync. What is our resync in principle? Just copying files. Let's keep the things simple - it works, if you think out mechanisms before you start to implement projects ... On the contrary, our transport department bought external system done in Visual Foxpro (but it doesn't matter). It's a typical example of MS Windows grown programmers. You have to do several installs and you have to personally visit each station because of registry dependency (as some of modules are not server based) Don't mix Windows app creation guideliness stupidity and general usage of windows/system (or other) directory for app components placement with simple incremental solution which can work 100% flawlessly for you. Those of you using app installers for your own apps inside your company - I can't understand you - that's my message to you :-) There is not more elegant solution than let Novell login script to execute rebol/view script, telling new user new app is coming to his/her desktop, copying all files into one and only app directory, and place icon automatically on desktop. old Amiga motto: KISS :-) Cheers, -pekr-

 [24/27] from: agem:crosswinds at: 16-May-2001 21:45


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 16.05.01, 16:15:35, schrieb "GS Jones" <[gjones05--mail--orion--org]> zum Thema [REBOL] Re: Commercializing Rebol:
> From: "Ken Anthony" > <snip>
<<quoted lines omitted: 9>>
> executable file. The components are reached through the database > system. The end user only sees and deals with the one file in a
typical
> scenario (as always, there is a little more to the story...). It is > the concept on which I am focusing, and the concept seems very neat.
It
> also seems "doable" in REBOL, at least in principle. Problems remain; > this solution is hardly a panacea.
Its mostly easy with rebol. I played with a filesystem + content in a scripts, which is available thru a scheme (ram://). I can switch the scheme, so on development it simply accesses hd and on distibution it accesses the ram-cache. Some problems because some stuff can only be done with files, not urls ('change-dir and with it 'system/script/header/file) but mostly one can have a whole filesystem in a script. Since its a scheme, one can easy copy from hd to ram:// and back , or making a scheme ram2:// from it..
> KA> I will worry about size and how to update. While in principle, > incremental
<<quoted lines omitted: 3>>
> Oh, so true. Just supporting my wife's cobbled together eBay and > website management scripts is more work than I care for it to be, but
I
> believe that a scripted document-type approach would be easier in our > case. > As an aside, one might ask why not just use Tcl/Tk and the > aforementioned package. I was going to, but I have this mental block
on
> the Tk model for a gui. I just never got up to speed in Tk, certainly > in comparison to /View VID. > This single, "scripted document" arrangement is a very compelling > concept to me, putting aside, for the moment, Petr K's well founded
and
> easily understood concerns. I have additional and, as yet,
unexpressed
> concerns and reservations. One is the idea that any data is ever > encoded in a non-directly readable format. Legacy problems become
<<quoted lines omitted: 5>>
> format and yet quickly addressable and compressed! > --Scott Jones
Volker

 [25/27] from: robert:muench:robertmuench at: 16-May-2001 9:21


> -----Original Message----- > From: [rebol-bounce--rebol--com]
<<quoted lines omitted: 5>>
> I have checked this one out before - very > interesting indeed.
Hi, I just looked into it, really looks interesting. If anyone has any experience with it please let us know.
> Having a bit of trouble figuring out the cost though. :-)
?? Why this ?? Did you contact them?
> http://www.softwareag.com/tamino/
This one I know a bit, it was evaluated by a team I know. They were very impressed by Tamino's power etc. but seems to be quite expesnive. Thanks for the other links. Robert

 [26/27] from: robert:muench:robertmuench at: 16-May-2001 11:13


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> would like to see for REBOL applications meant for distribution to the > general public (meaning, less than truly computer-competent).
Hi, maybe someone from RT can have a look at it, for RT it should be a no-brainer to create the right solution ;-)).
> The REBOL > runtime (and runtimes yet to be) apparently achieves some of these > goals. An expanded wrapper-type solution including database would be > ideal.
I like the wrapper idea, too. It's really nice to be able to pack everything you need into one EXE file. I hope RT will expand this idea further. Since HD space is so cheap I really don't like the shared-library concept anymore. How many time have you lost because of problems with shared files, wrong versions etc.? Just compile everything into one file and that's it. I prefer to waste some space on my HD than time. Robert

 [27/27] from: robert:muench:robertmuench at: 17-May-2001 14:46


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 7>>
> executable file. The components are reached through the database > system.
Hi, I really like the idea using a small database system to distribute/store/update script (components) on different systems. Imagine a collection of Rebol scripts (collection of functions, generators etc. short: components you can re-use and combine) stored in a database and now an appliction, which let's you "construct" your new application from these building blocks... I like it!
> concerns and reservations. One is the idea that any data is ever > encoded in a non-directly readable format. Legacy problems become > built-in, and this seems to be a bad design choice make from the very > outset!
That's right. But I think there is no silver-bullet: 1. We want fast and comfortable handling --> database system but not human readable. 2. We want human readability, instant access --> plain text files. IMO, all the data from the database should be exportable into a human/machine (XML?) readable style to be processed in an other way. Having two set of data might help: A text represantion of everything, just as reference and a working version integrated into a database. Robert

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted