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

Cookbook submissions idea

 [1/17] from: jason:cunliffe:verizon at: 5-Jan-2004 17:29


first gotchas might be useful category.. You know the crucial little things which tripped you up till you went aha! - Jason

 [2/17] from: gerardcote:sympatico:ca at: 5-Jan-2004 19:31


Hi Jason,
> "first gotchas" might be useful category.. > > You know the crucial little things which tripped you up till you went aha! > > - Jason >
This is exactly in the spirit of what I was thinking about ... Who will be the first runner up to fill this need - just a single try or two for each one of us will do the job to start I think. And even under this large umbrella we'll run a long time if we want. Imagine all the gotchas everyone got trying VID, View, Draw, Core (constructs, datatypes and conversion, objects, coding style, etc...), installs, internals docs and hard to reveal discoveries found after long lasting night(s) ... Thanks (in the name of all others who are trying again ...) , Gerard

 [3/17] from: maximo:meteorstudios at: 5-Jan-2004 20:13


something like this: -words are not variables. !! words are LIKE variables with context. !! -there are no statements in rebol !! only expressions !! creating your own "statements" - the 'ENUM example (generating words with values based on list of words ) - the 'UNLESS example (now part of view 1.3) - the 'STATEMENT example (a function which striped of return value) example that creating functions is actually an expression like all the rest. Things we could mirror in a real-time rebol doc viewer / web page cookbook tool: -per word examples. one index page per rebol word. would include code (preferably one or two lines) and generated effect (print result, view face, etc...) some explanations are also a must, of course (like why or how). -per facet examples. one separate index page per FACE facet. numerous examples for each facet. -per style examples. one separate index page per standard vid style. numerous examples of each VID style and how it works/reacts All submitted as make doc (pro) files, as plain text, or as ubber simple html with strict guidelines (offending layouts not included in cookbook). -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [4/17] from: atruter:labyrinth:au at: 6-Jan-2004 13:10


The one that always gets me is:
>> a: [b true]
== [b true]
>> c: 'b
== b
>> a/:c
== true Now how does one do "a/:c: false"? Regards, Ashley<

 [5/17] from: maximo:meteorstudios at: 5-Jan-2004 21:55


I've never been ablr to find a way to make that work, but this would be the answer if you haven't found any answer to the riddle... a: [b true] c: 'b ;-) next line works change next find a c false probe a == [b false] -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [6/17] from: gerardcote::sympatico::ca at: 5-Jan-2004 22:42


Hey Max, Congratulations! You simply hit the bull's-eye !!! We simply miss some formal structure as to how and what has to be officially presented. May be the scripts library committee or other REBOL and/or DOC expert can help us to start with ... Finally someone must also be chosen as the One who will in the end decide of the final product contents and look and feel !!! Some volunteer or proposed with some supporters ??? There are many good ideas already sitting down here on the table ... Regards, Gerard

 [7/17] from: SunandaDH:aol at: 6-Jan-2004 5:27


Hi Gerard:
> We simply miss some formal structure as to how and what has to be
officially
> presented. May be the scripts library committee or > other REBOL and/or DOC expert can help us to start with ...
There isn't a committee on the script Library as such -- just Gregg, Volker and myself. Anyone who joins the Library is free to contribute any script they want. Sometimes, that shows up a flaw in the cataloging features (we don't have pre-thought of categories for the new script), but we can normally add new categories pretty quickly. Robert Muench proposed REBOLDOC sometime back. That would be a website with extended user-contributed examples and documentation for each REBOL word -- so you could look up various tricks and traps for say 'if or 'open. He asked for volunteers to help him develop it back in aug-2003. If the project is onhold awaiting a kindly volunteer maybe, Gerard, you could be The One! I've thought a couple of times of having a "Gotchas" section on REBOL.org -- we'd use the cookbook idea and format, but for traps or version/platform-specifc issues. But I don't have the time in the first half of this year, so I'd be very happy for someone else, or some other site, to do it instead. Sunanda.<

 [8/17] from: robert:muench:robertmuench at: 6-Jan-2004 14:24


On Tue, 6 Jan 2004 05:27:00 EST, <[SunandaDH--aol--com]> wrote:
> Robert Muench proposed REBOLDOC sometime back. That would be a website > with extended user-contributed examples and documentation for each REBOL
<<quoted lines omitted: 3>>
> project is onhold awaiting a kindly volunteer maybe, Gerard, you could > be The One!
Hi, yes that's right. Even I'm going to repeat myself here over and over. IMO the biggest enemy is "information fragmentation". We have a lot of information burried in the ML, many very good Rebolers in the community, several good web-sites, etc. We just don't consolidate these information snippets in a central base. For reference IMO it's a must to have a central base. The Rebol library shows how good this approach works. The idea to send a status mail to the ML is very good! With the ciritical mass of information, gravity will ensure that more and more is put into the library / docs. Anyway, I see some requirements that must be fullfiled to make this a success: 1. Easy to use! New Rebolers, people just giving it a try, etc. want to download one file and click thru it. I can imagine something like a standalone easy-vid application. I have the SDK so we can create this. Of course the source version will be available too but new people need to get it very fast. 2. Some Master! IMO we shouldn't spend to much time to questions like: What categories do we need , "In which order do we add content" etc. We need someone how has the vision, and how keeps the rest of us on track. If people submit stuff for Rebol words, well than we just use it. Over time it will fill up. This is not a static project. 3. Make it pure Rebol! IMO the best we can do to show what Rebol is about is to create an super-easy-vid like tool for all kind of Rebol documentation: Core, View, VID, IOS etc. The Rebol knowledge-base... 4. Peer-Reviewing! The Master is responsible to share the vision and keep the rest on track, motivate people and get input. To ensure a good quaility, I think we should setup a peer-review group. This group will check new submissions, before these are integrated. Peer-review members should be suggested and voted on. As I'm far away from being a Rebol expert WRT to View & VID, I just started together with Steve, to collect all kind of information snippets about View / VID. We try to hack together an as-much-complete documentation as possible. I could need such a thing very often, as I'm not working with this stuff all the time and I'm forgetting things to fast. But I'm able to pick up very fast, if I can have a look at very simple examples. So, what do we do next? Robert<

 [9/17] from: gerardcote:sympatico:ca at: 6-Jan-2004 8:41


Hi Sunanda and others contributors to the actual Library and Documentation systems, I'll be glad to help the community as much as in the sense of doing some work cataloging submitted scripts, ideas and the like as I would have liked to get them used myself from the start I learned REBOL. However remember that I am a starter as I begin again to learn REBOL since I was not started a long time with ot as I had to go down for another too longggg illness period ... I really have to start it all and I'll do it quietly this time. At least I know that I can count on you all to guide me and react quickly if something is not up to the level you want it to be. I'll sure contact Robert about REBOLDOC just to see if his project goes in the same direction as the one you mentioned. May be using a gotchas section in the actual cookbook, library or in the form or easy-vid lessons could be enough to start with. In any case if you have any material (ideas, comment, code for simple examples) to submit about how to use each REBOL word, I'm opening the entries. I have found many myself but they have to be organized and edited somewhat. Later a section about some very small to small projects to be developed (from design to code and doc) could be fun to put in place too. Not just the final product but a full way of thinking guideline for real things. I know that everybody here has its own way of thinking but if books and teachers can do it for other languages why could we not do it for REBOL. I also there is also a lot of material on the REBOL basics but not much about how to develop small projects from beginning to end in the spirit of REBOL designer. The official book shows some but they are not trivial to me and we can do it simpler for beginners I think. I think the cookbook is the nearest of what I think about for now followed by the simple VID examples contained in easy-vid. If I speak for myself I recently found enough starting material in the cookbook to really begin to understand how I can hope interfacing some REBOL code with a functional GUI that will really use some text list with sliders and react correctly to my users' mouse events without having to ask everyone for the tiny details I couldn't find myself from the VID or VIEW sources ... after having looked in the docs too. In fact it's a bit too low level for me when I want to do something quickly a la VB. I suppose it is so for many newcomers and this could be eased in some way for them if we only want to do something small without having to reinvent the wheel everytime. This is why I like the idea of having some plug and play library at hand for us to use - even if we have to parameter it each time. Regards, Gerard

 [10/17] from: gerardcote:sympatico:ca at: 6-Jan-2004 9:01


Hi Robert, consider we are now 3 on your REBOLDOC workers' list, I propose you (if you agree) as our first Master to share your vision and keep the ship in the right direction and we'll try together to get the peers review committee on foot and alive. Give me some link referring to what you found up to now that I begin to study and review what you have at hand for the moment. I'll be glad to add to this material myself and look around for additional stuff - even query some when needed if I can't produce or get it myself. I also share the idea of getting some standalone product in the easy-vid format. Glad to reconnect with you for work and pleasure - our former connection was broken too soon. I'll come back at it later if you permit. for now I have to relearn REBOL with greater detail and learn VID too. Regards, Gerard

 [11/17] from: jason:cunliffe:verizon at: 6-Jan-2004 13:54


> Robert Muench proposed REBOLDOC sometime back. That would be a website
with
> extended user-contributed examples and documentation for each REBOL
word -- so
> you could look up various tricks and traps for say 'if or 'open.
Vanilla could be a great tool to use for that:-) http://www.vanillasite.at/space/start If Gerard would take charge, I'd be willing to help out since I've been working with Vanilla for some time. Meanwhile, RIT [Rebol Institute of Technology] site is the only Vanilla site which is dedicated to Rebol already. So perhaps the Graham has an idea ? http://compkarori.com/vanilla/display/rebol-main - Jason

 [12/17] from: gerardcote:sympatico:ca at: 9-Jan-2004 10:07


Hello Jason,
> > Robert Muench proposed REBOLDOC sometime back. That would be a website > with > > extended user-contributed examples and documentation for each REBOL > word -- so > > you could look up various tricks and traps for say 'if or 'open. >
I didn't find any info about this REBOLDOC project on Robert's website (Saw an OpenDOC entry but nothing else) Robert can you comment about this please ?
> Vanilla could be a great tool to use for that:-) > http://www.vanillasite.at/space/start >
I also went from there to Langreiter's one and really love the revealing aspect of the demonstrated TouchGraph as used there to index and relate the interconnection of snips (small information chunks linked together by hyperlinks) I visited it and found some small REBOL notes from Holger and others that could be indexed since they explain some important misconceptions ppl tend to have when starting with View - compared with VB for example. I can try to start one locally but I have no Web server that can help here to publish anything on the Web for reviewing, commenting and editing by other ML members. In this case I would prefer to install a plain wiki I got many years ago that worked well here locally the first time I tried to install it - remember it was not the same at all with Vanilla. However if someone desires to host me for this project and give me some access to his own Vanilla operated site, I'll be glad to accept his invitation. What do you think about ? Don't forget that the main points here are simplicity, visibility and sharing of ideas and code.
> If Gerard would take charge, I'd be willing to help out since I've been > working with Vanilla for some time. > Meanwhile, RIT [Rebol Institute of Technology] site is the only Vanilla site > which is dedicated to Rebol already. So perhaps the Graham has an idea ? > http://compkarori.com/vanilla/display/rebol-main >
Thanks. It's been a too long time I didn't visit Graham's site. Last time I think it was not operating a Vanilla site at all.

 [13/17] from: robert:muench:robertmuench at: 10-Jan-2004 13:41


On Fri, 9 Jan 2004 10:07:45 -0500, Gerard Cote <[gerardcote--sympatico--ca]> wrote:
> I didn't find any info about this REBOLDOC project on Robert's website > (Saw an OpenDOC entry but nothing else)
Hi, first I'm working on my new site. Hopefully I'll upload it this weekend :-). Well, there is not much to say about it. It's only an idea so far. I haven't started coding anything.
> I can try to start one locally but I have no Web server that can help > here to publish anything on the Web for reviewing, commenting and > editing by other ML members.
I have web-space, we can host the stuff there.
> In this case I would prefer to install a plain wiki I got many years ago > that worked well here locally the first time I tried to install it - > remember it was not the same at all with Vanilla.
Well, my idea with REBDOC was to create an easy-vid like tool, for a complete Rebol documentation. So, there are two parts to the project: 1. The tool 2. The content The hard part is 2 ;-) IMO it makes sense if we create a plain good old faishoned Rebol documentation paper. One big HTML page etc. IMO we don't need an other Wiki. My idea is to create a manual you can read front-to-end, not a fragmenting pool of snippets. First, we have enough such pools, second, those only help you if you know quite a lot about Rebol. Robert<

 [14/17] from: jason:cunliffe:verizon at: 12-Jan-2004 18:06


Hi Gerard
> I didn't find any info about this REBOLDOC project on Robert's website
(Saw an
> OpenDOC entry but nothing else)
...perhaps this explains http://www.rebol.net/list/list-msgs/30437.html Regarding Vanilla. First, good idea to post Vanilla questions to the dedicated list "vanilla-pudding". Little traffic, but makes Vanilla study easier for oneself and for others who come behind because they don't have to filter out Vanilla posts from zillions of other rebol ones. I think everyone who knows Vanilla from hands-on experience subscribes [all ten of them] Link for vanilla-pudding are here http://www.vanillasite.at/space/documentation
> In this case I would prefer to install a plain wiki I got many years ago
that worked
> well here locally the first time I tried to install it - remember it was
not the same at all
> with Vanilla.
There certainly other wikis one can use. All are probably more fully documented and have larger user communities. But since this project is about REBOL and about learning it, may be best to make small initial sacrifice of convenience, and use a rebol-based tool. Once Vanilla is installed and you start to understand its design, you'll appreciate how cool it is , how much fun it is to modify, and at times also how frustrating it can be there are not more people using and developing it [deja-vu?]. So deciding to using it is a symbiotic strategy -- helping rebolers and at same time helping vanilla grow though that..
> However if someone desires to host me for this project and give me some
access
> to his own Vanilla operated site, I'll be glad to accept his invitation. > What do you think about ?
I am willing to host a fresh vanilla-site on one of my dreamhost.com domains and give you full access you'd need. It is not the fastest because I don't have fast-cgi running nor a dedicated server. Can't justify that server cost yet.
> Don't forget that the main points here are simplicity, visibility and
sharing of ideas
> and code.
And its about learning REBOL right? Best way to learn rebol is to use it... Vanilla just needs more hands and eyes on it. A very important task is documenting it from developer perspective. Vanilla is easy to use. Clear documentation may almost be the best reason to do this project together using it, because it will naturally encourage us to create something very valuable which the community lacks. I n addition to virtues, I am enthusiastic about Vanilla also because it is one the most sigfnicant Application written in Rebol that I know and could be a nice poster child for Rebol web apps, even though it is just a cgi application at this point. It would not be hard to create many useful non-cgi rebol tools for shell and /View designed to work with Vanilla in the background. File uploading, peer-peer, site, updating and transfer, site-site features, remote site management. One dream is to build in a publish-to-Vanilla button for easy-vid. It useful to look at Dave Winer's Manila and Radio Userland products when considering full application possible with Vanilla I have a big to-do list of projects for extending Vanilla. Most focus on improving its capabilities for collaborative art and educational uses, with better implicit support for graphics, dynamic flash, auto-upload, sharing, permission, groups and access management. Almost all involve writing tool which exploit custom snip metadata. I 'd also like move vanilla's code to Leo to help documentation and to manage and merge developments, but simple basic documentation comes first. A few very simple things I have done already: custom metadata, interactive calendar, template selector. - Adapted the default calendar in Vanilla. For example see http://tranzilla.net/vanilla.r?selector=display&snip=2003 Uses CSS now. I like the year display because it is a nice overview and edit interface in one. - Added better templating The default 'selectors' are 'display', 'edit' etc. I added one called 'display-template' which let's one define the template skin no the fly via the url. To see what I talking about, click the snip=2003 url above, then try the various links in at-a-glance - - DAY, WEEK, MONTH, YEAR and look at the url they produce Then click the 2003 and you'll see it is set to define its own template http://tranzilla.net/vanilla.r?selector=display-template&template=tiny-template&snip=2003&template=vanilla-template The first param call: "template=tiny-template" is the which default I set display-template to use and display But the second template call overrides the first so template=vanilla-template If you change that to vanilla-template2, vanilla-template3, vanilla-template5 you'll se how easy it is to change the entire screen. My demo could; be much better because I've not done anything graphically interesting yet with them. Vanilla templates are actually an editable vanilla 'snip' or element. And they can dictate what components an functions will be on the page and also define CSS file link. So there are now several levels one can use to change vanilla look'n'feel very quickly via a url :-) An important to-do feature for the templating is to have an auto-template option. Then 'snips' could define their own preferred template by storing its namevalue in their metadata. If auto-templating is enabled then the page will just switch to use that. All snips in Vanilla have their own private associated metadata files. This is the killer feature in Vanilla. There are system-wide metadata fields, but its easy to add and use custom ones. once a metadata field is added to a snip its value can be accessed and displayed with {.metdataname} for example {.name} ;this snip's name {.last-editor} ;the id of the last person who edited it At the bottom of my pages you'll see a form which lets one create custom metadata [permission required]. A few more metadata management tools with form interface are top of my to-do list
> > http://compkarori.com/vanilla/display/rebol-main > > > Thanks. It's been a too long time I didn't visit Graham's site. Last time
I
> think it was not operating a Vanilla site at all.
No its running. Not much traffic - that's a risk of all these new rebol forum/site experiments. Graham did some hard fast study getting up to speed with Vanilla. See the clump of his valuable posts in the vanilla-pudding archives. I remember one important thing he did early on was to make it friendly for displaying rebol source code. Anyway, I just downloaded the latest version of Vanilla [0.6] . I need to create a fresh site with it then and figure out how to include in my earlier customizations. So hopefully soon we can experiment together and you can see decide whether or not you like it. AI have to do this anyway so no problem if you opt to go some other route. It'll still be there anytime and can be linked or copied. I think vanilla-vanilla communication woudl be really cool. Plus being able to generate an entire vanilla site from a script or export from some other app. That could save a *lot* of time and be an intrinsic part of site-site iport export and mesaging as well as publish-to-vanilla feature of Easy-Vid Thats inspireed by my experience with Zope where you can import and export a site or branches of it via a single cross-platform .zexp file. Its beautiful to see in action hope this makes sense - Jason

 [15/17] from: petr:krenzelok:trz:cz at: 13-Jan-2004 0:59


Jason Cunliffe wrote:
>Hi Gerard >>I didn't find any info about this REBOLDOC project on Robert's website
<<quoted lines omitted: 9>>
>dedicated >list "vanilla-pudding".
sorry to snip your whole talk about Vanilla. While Vanilla or Wiki, whatever may be nice design to study, I think you overestimate its usefullness for Rebol. I am sorry to very strongly back-up Robert's pov, but I can bet that if free version of IOS like sync mechanism would exist, much cooler scenarios could be created - with rebol, for rebol - entire network could grow. Don't get me wrong - how is it usefull to study and deploy non rebol mechanism to document and learn what is rebol capable of? Of course web-interface is still important nowadays but when I hear talk about Vanilla to Vanilla communication and similar kind of stuff, you ppl are working agains basic idea of rebol then, no? - messaging ... I want rebol way of messaging, not some http, cgi kludges - what is new about that? For what do we want to use rebol then if not for rebol native messaging in the first place? I am far from being good coder to do it myself, but I found things like Rugby way superior to popular things like XML-RPC. What is so innovative about it? Its wide popularity? It is a pity Doc did not finish multiprotocol engine - Uniserve, - run-time pluggable multi-protocol architecture. Wouldn't it be better to communicate to irc, jabber, rebol native way of course, etc.?We have Gabriele, Doc, Romano, Maarten, Gregg cool rebol networking protocols hackers here and I wonder why our community was not able to come up with something rebol related. Do we really lack innovation? -pekr-

 [16/17] from: jason:cunliffe:verizon at: 12-Jan-2004 21:18


Petr Krenzelok wrote:
> sorry to snip your whole talk about Vanilla. While Vanilla or Wiki, > whatever may be nice design to study, I think you overestimate its > usefullness for Rebol. I am sorry to very strongly back-up Robert's pov, > but I can bet that if free version of IOS like sync mechanism would > exist, much cooler scenarios could be created - with rebol, for rebol -
Hey no problem Petr. Thanks I really welcome different perspectives. I am sure much cooler scenarios could be created IF..if ..if ..if you're right. And believe me I have plenty of my own big dreams for years about multi-user messaging applications. It's what led me to Rebol :-) The web is extremely useful and I don't think it is going away. Interoperability is good. There is [hopefully] gainful employment to be had. I am also a big fan for years of desktop peer-peer apps which co-habit seamlessly with the web and each other. For example, I tried to do that with Zope in an EU-funded project 5 years ago. My design had a single download/install .exe which included Zope so that we could multi-user collaboration for off-line and online access. Many end-users only had occasional dial-up modem access. What is nice is that Zope bundles several servers FTP, WebDav, http, and can be remotely controlled by XML-RPC also. The project was for inter-modal transportation and needed to interface shippers, agents, truckers in several countries and juggling shifting calendars against itinerary and capacity.User interface was html + flash, with extra shipping database in BerkeleyDB wrapped as Zope product. Good ideas but too steep learning curve, too soon for the technologies used. Not enough other Python/Zope/Flash people in the project. So one painful lesson for me was that if you use a rare/new technology/paradigm you have to cover yourself and make sure it interfaces well with other mainstream systems as much as possible, and/or is completely transparent. Anyway I just like Vanilla. And after expecially Zope I adore its simplicity, though cannot compare them. I see personally see quite a bit of untapped potential in its design. I have some ideas about websites which I want to explore. And since Vanilla is written in Rebol, I can hope that someday Vanilla or something like it will also talk more with other cool rebol developments. Like Easy-Vid :-) I wish oh wish that there was a better solution than the feeble cgi dependency which vanilla has now. I wish there were a mega cool rebol universal server framework --- http, ftp, rebol, XMPP[jabber], plugin-architecture modular, cross-platform,fast install, etc. But there are simply too few experienced rebol programmers out there. You are all very talented and dedicated, but only so many hours in all our lifetimes. And few eyes yet to support documentation, testing, fixes, all that must go into building the momentum which the best openSource projects enjoy. So yes it's very hard to make progress. But we each are working on areas we feel motivated to. I am not a very good coder. I wish I was better and faster. So much I want to build. One reason I like Vanilla is that it is quite easy for me to extend. There is a framework I mostly understand now. Hacking Vanilla has helped me learn rebol a little and provided motivation and satisfaction. I don't know how long before I move on from thinking about Vanilla honestly. Speed and scalibility worry me. If I was smart I'd just use some Python or learn PHP and pick a tool that already everything and play with them. But trouble is I am hooked on Rebol/Vanilla. If I don't get some very so often I get the blues.. Do you know a doctor who can help me? And besides Gerard was looking for a platform/site to host beginner rebol help. One of the big problems still is that rebol is badly off the google radar. That's pretty bad for beginners. Rebol.org is great progress though. btw Google for some reasons seems to like Vanilla.... :-) - Jason

 [17/17] from: petr::krenzelok::trz::cz at: 13-Jan-2004 14:51

rebol deployment (was) Re: Re: Cookbook submissions idea


Jason Cunliffe wrote:
>"Petr Krenzelok" wrote: >>sorry to snip your whole talk about Vanilla. While Vanilla or Wiki,
<<quoted lines omitted: 9>>
>IF..if ..if ..if >you're right.
No problem, your arguments seem to be pretty fair, so ... just few comments ...
>Anyway I just like Vanilla. And after expecially Zope I adore its >simplicity, though cannot compare them. >
It is just two weeks one of my friends visited me to help me to install Fedora server. He brought two books with him - Cocoon and Zope. Zope seems to be interesting, he showed me how he used some module for digital photo catalogue. Nice, but really nothing what could not be done in IOS in a MUCH clearer way, at least to me. He admited, that Zope is nice even for beginners, but once you decide to modify some unsupported functionality, you have to go deep python. Reblets seem to be really better aproach to me. But of course - once you want your "output device" to be web (html), not a View/IOS client, you are in trouble a bit. Typical example is our current project - we will use IOS for regional info system - mainly few info-centres cooperating, but also automatic kiosk synchronisation. Should be a snap - we just need windowless ios client, which will be installed on each kiosk - should work. So far so good, but - our city info centre aproached us and asked for other output device - web portal. And suddenly my plans were broken, although I think I will handle it somehow. So primarily, for kiosk local access, or info-centre ppl local pc access, IOS file storage should be enough. There is e.g. some tens or hundreds of hotels, pubs, restaurants etc. in our region. But - I hesitate to run web portal upon scattered, non indexed file storage as IOS uses. So either I interface IOS with mySQL directly on server, or I write some off-line scripts, running as cron job, which scan particular ios directories and import new record, apply changes to existing or even delete records from mysql. And suddenly we are talking not so clear solution, which could easily become kludge, sooner than later.
>I wish oh wish that there was a better solution than the feeble cgi >dependency which vanilla has now. >I wish there were a mega cool rebol universal server framework >--- http, ftp, rebol, XMPP[jabber], plugin-architecture modular, >cross-platform,fast install, etc. >
There is - Uniserve - released as beta, the engine is just 10KB of code IIRC. I also remember some AltME chat, where some test of Uniserve multiplexing engine + http + cgi handler gave performance of Apache 1.x family + cgi + rebol IIRC.
>So yes it's very hard to make progress. But we each are working on areas we >feel motivated to. I am not a very good coder. I wish I was better and >faster. >
me to ... and what is more - I like "thinking" :-) I simply want to have some things thought out first, then touch coding eventually, but I know it can be drawback too, as experience comes from testing too.
>I don't know how long before I move on from thinking about Vanilla honestly. >Speed and scalibility worry me. If I was smart I'd just use some Python or >learn PHP and pick a tool that already everything and play with them. But >trouble is I am hooked on Rebol/Vanilla. If I don't get some very so often I >get the blues.. Do you know a doctor who can help me? >
PHP, Python etc. While we are at it, I noticed other factor. How often do we hear someone uses rebol to generate php, C# etc.? Well, ad for C#, probably only Andrew, but as for PHP? And I have to ask once again. What speed do you gain by generating php code from within rebol and letting certain apache module execture your php code? So we've got rebol/base - should be faster. How many times? Any benchmarks? Well - then there is FastCGI - looking at its architecture, it even seems to me much better than direct apache module. You may claim that it is contained in Command - but - the procol is fully and properly described and I have once again to wonder - why someone prefers generating php instead of writing fasct-cgi rebol-level driver? So we would have rebol/base + fastcgi - free solution, which would imo be even faster than combination of rebol + php. The only one drawback is - there is little web servers supporting fast-cgi modules, but when you run your own, why not? Carl also mentioned one thing. He was looking at one of Opera browser sites where some technologies were mentioned and no mention of Rebol once again. Maybe we could help here. We have mysql driver - why is not rebol there - http://www.mysql.com/downloads/index.html ? The same goes for other possible drivers/wrappers. That is the area we could help RT with for Rebol to start be visible! -pekr-

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