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