I agree. Useful discussion for things I'm thinking hard about these days as
I move away from Ruby on Rails and look for Rev-centric approaches to the
software projects I want to build.
On 3/28/06, Sivakatirswami [EMAIL PROTECTED] wrote:
I mean if the SSI ! include exec some rev.cgi. returns
Dan Shafer wrote:
Richard
I agree that merge is very cool and quite powerful.
Still, I cannot put into a Web page:
Hello, there. The time is % merge [[the time]] % (regardless of the
dellimiter being used around the call) as I can with Ruby. The merge
operation would, I think, have to be
Richard Gaskin wrote:
PS: For a fun take on the flipside of frameworks, this post at Joel is a
hoot:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
Ha! Great stuff, really!
Further down the page the author (IMO) does a great job of
differentiating libraries vs frameworks.
HI Dan,
I think the piece of the puzzle missing here is that of the web-
server. It is easy to configure Apache (for example) to execute a
particular program server-side when a page is requested that has a
specific extension. This program is passed both the requested URL and
resolved
Some great information in the replies by Richard and Mark Waddingham here.
Rather than quote them and intersperse comments, I thought I'd just make a
point or two in response.
Mark, you're right that the secret sauce here is training the Web server
to route pages to specific processes based on
On Mar 27, 2006, at 8:10 AM, Dan Shafer wrote:
That is where a Web app framework -- like Ruby on Rails, though
there are
several others worthy of consideration -- shows its strength. By
adopting
the model-view-controller (MVC) design paradigm, RoR creates an
effective
split between
OK, I've thought about this some more and poked at some of the CGIs you've
developed. The place where this include virtual approach to Web site
design breaks down for me comes at the point where, as I said in my original
definition, we have embedded command and function calls in the underlying
Dan Shafer wrote:
In any case, what is clearly NOT happening with an SSI is the inclusion of
Transcript commands or functions directly in the HTML file from which the
dynamic page is generated. All of the Transcript code is external to the
page layout/template. The overly simplistic example I
Richard
I agree that merge is very cool and quite powerful.
Still, I cannot put into a Web page:
Hello, there. The time is % merge [[the time]] % (regardless of the
dellimiter being used around the call) as I can with Ruby. The merge
operation would, I think, have to be included in the CGI
Sivakatirswami.
Wow. I gotta go try this as soon as I finish this talk I'm giving tomorrow.
And please send me those URLs you mentioned offlist. This could be HUGE for
me. I had no idea this could be done and I don't know why I didn't have any
idea this could be done.
On 3/24/06,
On 3/21/06 4:55 PM, Sarah Reichelt [EMAIL PROTECTED] wrote:
The alternatives that I see are to use script local variables or to
pass an empty parameter by reference and have the function fill it.
Does anyone have any other ideas or recommendations?
Here is another way that you could take
On Mar 16, 2006, at 8:13 AM, Richard Gaskin wrote:
I would imagine one could also set up Apache to use Rev for server-
side includes, using settings similar to what's used for Ruby or PHP.
I'm coming in here late on this but it's of great interest and very
relevant, because somehow, not
at www.himalayanacademy.com and www.hinduismtoday.com we use *only*
rev cgi's... and REvo remote clients
But, I have also installed PMwiki which uses PHP.
mod_php is presumably up and running all the time, but the rev
engine is being loaded on each instance of a cgi being called.
Sivakatirswami wrote:
If Anyone wants to see our CGI's I would be happy to put them
somewhere. Because I am not a developer, they could be easy for
newbies to re-use. I see a lot of different places not where this kind
of offering could be posted and one doesn't know which is best.
Thanks
First, this isn't all that long -- 98 lines -- but in any case I'd
consider:
-- breaking out routines for local vs. server connection
-- breaking out a routine for when we're just counting records that
match vs. returning data
-- breaking out a routine that, given a itemList describing a
Sarah Reichelt wrote:
OK, I have a better example. Say I have a data set and I need to loop
through it and extract three different pieces of information e.g. a
list of the 4th column in each line, a list of lines that match a
certain set of criteria, and a cumulative total obtained by adding a
Hi Geoff,
-- breaking out routines for local vs. server connection
You're ignoring my notes: application requirement: the calling syntax
must be identical for client, server, and single user.
-- breaking out a routine for when we're just counting records that
match vs. returning data
On Mar 22, 2006, at 7:34 AM, Rob Cozens wrote:
Hi Geoff,
-- breaking out routines for local vs. server connection
You're ignoring my notes: application requirement: the calling
syntax must be identical for client, server, and single user.
That's fine -- I'm just saying that the
Geoff,
-- breaking out routines for local vs. server connection
Client selection [server opens all dbs as local connections]:
replace return with numToChar(29) in itemList
replace return with numToChar(29) in searchCriteria
requestSDBService
Geeze Geoff ,
If I've offended, I apologize.
I thought you knew me better than that. :{`)
If I've come off pedantic or emotionally upset, then I'm sorry.
There is no right or wrong answer, it's a matter of preference...and my
preferences are closer to Chipp's than yours in this matter.
Geoff:
on doSomething pArg
if tSingleUser then
doSomethingForSingleUser pArg
else
doSomethingForMultiUser pArg
end if
end doSomething pArg
doSomethingForMultiUser pArg
is the seven lines I used as an example in my last post, the remaining
90 lines comprise
Geoff,
Because it gets rid of a bunch of if statements in your repeat loop.
It costs you a bit in that the repeat structure is duplicated in the
routine that simply counts, so that's a tradeoff. But your repeat ends
up being faster because you aren't doing tests each time through.
Further,
Sarah, Mark, et al:
arrays are things that don't come
naturally to me, so I probably ignore them when they would be useful.
Arrays, in the traditional sense (ie: element(1)...element(n)), were
part and parcel of my programming instruction in BASIC and my first
professional programming in
On Mar 20, 2006, at 6:20 PM, Sarah Reichelt wrote:
I haven't ever really tested it and I have an instinctive feeling that
functions should be self-sufficient and shouldn't change anything
outside them. Maybe it will suit me better in some circumstances.
This is true, but passing by reference
Wow -- so what does this do?
On Mar 20, 2006, at 9:28 AM, Rob Cozens wrote:
Hi Geoff,
Out of curiosity, do you have an example handy of a long handler
that you think makes more sense to keep together than to break up?
Or one that you think can't be broken up without significant
effort
Hi Geoff ,
Wow -- so what does this do?
From Serendipity Reference:
The findSDBRecord command checks for the existence locked/unlocked
status of a record with the record type and key specified in line 1 of
sdbBuffer. It can also be used to unlock a record that was previously
locked
On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote:
Do you have an example? I agree that if you end up passing in a
handful of arguments by reference, you haven't accomplished much by
breaking out the routine. The question is if there isn't a better way
to slice the routine, where that wouldn't
You might put the multiple results into the elements of an array, and
return the array.
Mark
On 22 Mar 2006, at 00:55, Sarah Reichelt wrote:
On 3/21/06, Geoff Canyon [EMAIL PROTECTED] wrote:
Do you have an example? I agree that if you end up passing in a
handful of arguments by reference,
I didn't think of that Mark. Again, arrays are things that don't come
naturally to me, so I probably ignore them when they would be useful.
In this case, it sounds like a really good solution.
Thanks,
Sarah
On 3/22/06, Mark Smith [EMAIL PROTECTED] wrote:
You might put the multiple results into
I'm just a simple Caveman programmer. Your advanced technology and talk
of arrays and multiple functions frighten me. In this case, I'd just as
soon keep thinkgs in a single handler which cavemen like me can read and
debug easily.
:-)
-Chipp
Sarah Reichelt wrote:
I didn't think of that
Out of curiosity, do you have an example handy of a long handler that
you think makes more sense to keep together than to break up? Or one
that you think can't be broken up without significant effort to do it?
When you think of a long handler, do you generally think of it as
having a
Are you the new listmom?
sqb
Hey gang,
Im not naming names but Im feeling some heat when it's about time I enjoy a
nice Sunday evening with my family - lets leave the past in the past and
kill this thread. If you want to continue on an individual basis on this
topic, then please email each
Hi Geoff,
One does come to mind, it's the startup handler(s) of my splash stack,
and they are broken down serially into 7 or 8 different handlers, each
numbered sequentially with a handler name.
And because I want to be able to read them one after the other, I ended
up programming them
On 3/20/06, Geoff Canyon [EMAIL PROTECTED] wrote:
Out of curiosity, do you have an example handy of a long handler that
you think makes more sense to keep together than to break up? Or one
that you think can't be broken up without significant effort to do it?
When you think of a long handler,
This sounds like a bunch of small handlers masquerading as a large
handler ;-)
Nothing wrong with that, I just think it means that you're really on
my side of the big/small question, except that you don't like the
surplus of handler names it leads to. I can certainly agree with
that.
Do you have an example? I agree that if you end up passing in a
handful of arguments by reference, you haven't accomplished much by
breaking out the routine. The question is if there isn't a better way
to slice the routine, where that wouldn't be necessary.
On Mar 20, 2006, at 4:29 AM,
G'day Sarah,
In my experience, it's probably due to never passing values by
reference.
I'm curious as to why you eschew passing by reference.
If one needs to pass large variables, why incur the overhead of
duplicating the value of the variable before passing it? And if a
variable value
Hi Geoff,
Out of curiosity, do you have an example handy of a long handler that
you think makes more sense to keep together than to break up? Or one
that you think can't be broken up without significant effort to do it?
on findSDBRecord
On 3/20/06 9:28 AM, Rob Cozens [EMAIL PROTECTED] wrote:
on mouseTrapOn -- 3 Mar 04:RCC
insert the script of field Mouse Trap of card 1 of stack
Serendipity_Library.rev into front
end mouseTrapOn
I suppose you also have a
SerendipityDo_Library.rev
for those calls that need extra hold, eh?
Moi:
if itemNumber = 0 then put recordKeyfieldBelimiter after
returnRecord
Thanks for getting me to revisit the handler, Geoff: fieldBelimiter
was a bug waiting to bite me.
Rob Cozens
CCW, Serendipity Software Company
And I, which was two fooles, do so grow three;
Who are a
Hi Jim,
I suppose you also have a
SerendipityDo_Library.rev
It's still a work in process; but will be released as
SerendipityDoDa_Library.rev so folks won't think it's
SerendipityDoDo. :{`)
Rob Cozens
CCW, Serendipity Software Company
And I, which was two fooles, do so grow three;
Rob-
Monday, March 20, 2006, 10:04:01 AM, you wrote:
Thanks for getting me to revisit the handler, Geoff: fieldBelimiter
was a bug waiting to bite me.
...and that's why I'm such a stickler for declaring variables. If the
compiler can find your bugs for you, why not let it do the work?
--
On Mar 14, 2006, at 6:40 AM, [EMAIL PROTECTED] wrote:
Josh,
Very strong statements. Wow! If I may ask for further
clarification... I have two questions I'd love you expound upon.
1) RealBasic -- that's the main rival, as I see it. I haven't
written big enough apps to test, but it
Marielle,
I believe this response to Chipp is a unfair.
The post you cite regarding Jerry was apologized for almost immediately
after he realized that he sent it to the list and not to Jerry personally.
And I seem to recall Jerry being nearly abusive in the posts sent around
that time. I don't
On Mar 14, 2006, at 3:17 PM, [EMAIL PROTECTED] wrote:
So I anticipate that the web apps would be VERY simple, and it
might even be possible to push the date into something like PHP-
Fusion or Joomla!
Joomla = NO
WordPress = YES
e107 = YES
: )
from one who has done way too much
On Mar 19, 2006, at 12:55 PM, Mark Wieder wrote:
It's probably my forth background, but I'm mildly allergic to routines
that don't fit in their entirety onto my screen.
--
-Mark Wieder
[EMAIL PROTECTED]
Ah, I just realized why I'm writing overly complex handlers and not
using
OMG, Judy, two things we can agree on in, what?, less than a month? Perhaps
the end of the cycle is imminent!
:-)
I spent two years once trying to sell a product into the education market.
(I use quotation marks because in my experience -- which may well have been
unique for all I know -- there
On 3/21/06, Rob Cozens [EMAIL PROTECTED] wrote:
G'day Sarah,
In my experience, it's probably due to never passing values by
reference.
I'm curious as to why you eschew passing by reference.
If one needs to pass large variables, why incur the overhead of
duplicating the value of the
Well I think you are right - there would be better ways to split out
segments of the script, and if I find more than one routine neededing
to do the same things, I go to the effort of doing it. However at the
moment, I am mainly concerned with converting HyperCard scripts to
Rev, and so I like to
I think the point is that when a variable is passed to a function/
handler 'normally', the data in it is duplicated, and if the data is
big, this is not as efficient as passing it by reference - obviously,
if you need to change the data in the called function/handler, this
may have unwanted
On Mar 20, 2006, at 9:01 PM, Mark Smith wrote:
I think the point is that when a variable is passed to a function/
handler 'normally', the data in it is duplicated, and if the data
is big, this is not as efficient as passing it by reference -
obviously, if you need to change the data in the
Ever the metaphorical thinker, this reminds me of good gun safety
practices (aka ways NOT to shoot yourself in the foot) - it's all in
knowing how to control a powerful tool.
Phil Davis
(meant in a lighthearted way and limited strictly to the parallel
observed - not intended to engender
Holy Batcrap, Dan!
Like, is it a full moon? Are the planets in alignment?? Did I miss a
supernova somewhere obvious???
:-)
You know, I have always held that rumours of our supposedly concrete
disagreement status are greatly exaggerated.
Yeah, I've seen something very like what you are
Geoff-
Saturday, March 18, 2006, 1:24:50 PM, you wrote:
I've never seen a hundred-line routine that wouldn't be better as
five twenty-line routines, each of which could be documented with a
line of code. Perhaps even ten ten-line routines.
It's probably my forth background, but I'm mildly
If you aren't happy with the tool, then just don't use it. It's
that simple.
It is not very wise to say so. If all dissatisfied persons on this
list followed your advice, in the present context, this could cost
runrev very many clients. My personal view on this is that it is
better to
Yep, I've heard that before, but frankly, for me, I'd rather keep it all
in one, unless there's a really good reason to separate into multiple
handlers (as in creating more reusability). I find it much easier to
debug code I've written this way than hunting through the message path
for the 15
Marielle,
Notwithstanding your earlier private unsolicited (and unresponded to)
rants to me (and others) on why you hate Revolution, it is obvious you
like to have the last...oh 1000 words.
Bravo.
-Chipp
___
use-revolution mailing list
Marielle, I really don't get how anyone thinks that genuine and
justified criticism of Revolution is somehow not tolerated on this list.
On 19 Mar 2006, at 22:17, Marelle Lange wrote:
What I have seen on this list is that you just want to get rid of
the persons who tell you there is a
Hey gang,
Im not naming names but Im feeling some heat when it's about time I enjoy a
nice Sunday evening with my family - lets leave the past in the past and
kill this thread. If you want to continue on an individual basis on this
topic, then please email each other offlist.
Best regards,
Lynn
Hi Chipp,
Yes, this is a very relevant list, though some things have changed at bit.
He gave 3 reasons for this:
1) The culture. Great software is typically created by a
small group of only a few developers-- not the Japanese way
of throwing manpower at a problem. Furthurmore, typcially
Lynn-
Saturday, March 18, 2006, 6:33:05 AM, you wrote:
Another piece of software that is Japanese is --- the Ruby language.
Ah... you beat me to it. I was going to chime in about Ruby.
Lynn Fredricks
Worldwide Business Operations
Runtime Revolution, Ltd
...love the new sig...
--
-Mark
Hi Mark,
Any chance to see you post the relevant code on this list?
I read the ECMI document but don't remember the part describing
conventions for describing the API in a way similar to the one
outlined in the javadoc. Is it possible for you to cut paste the
relevant excerpt on this
On Mar 17, 2006, at 1:20 PM, Mark Wieder wrote:
...sure there is. You have to roll your own, but it's not that much
transcript code. My libraries generate their own documentation through
a javadoc-like mechanism. Check out, for example, my ArchiveSearch
plugin on revonline and open the
On 3/18/06 2:00 PM, Marielle Lange [EMAIL PROTECTED] wrote:
Hi Mark,
Any chance to see you post the relevant code on this list?
I read the ECMI document but don't remember the part describing
conventions for describing the API in a way similar to the one
outlined in the javadoc.
It's
Hey Dan, thanks for the quick note.
I think I get now. 8080 is already open. Launch this and the metacard
stack listens without changing any control panel stuff.
Just tried the following:
Safari
http://localhost:8080/~jault/
=== stack running as an app (dbl clk) no problems
Explorer from a
The missing link is the killer app made with it. RoR was virtually
unheard of before BaseCamp took off, showing the world how powerful
and flexible RoR is. If we had an app of similar scope and appeal
I have no doubt that as long as the engine is free for such uses
and the scripts are
Marielle-
Friday, March 17, 2006, 4:44:16 AM, you wrote:
many Japanese management concepts such as Total Quality Control,
Quality Control circles, small group activities, labor relations. Key
elements of Kaizen are quality, effort, involvement of all employees,
willingness to change, and
many Japanese management concepts such as Total Quality Control,
Quality Control circles, small group activities, labor
relations. Key
elements of Kaizen are quality, effort, involvement of all
employees,
willingness to change, and communication.
Having been involved with Total
Marielle wrote:
What you get with Java, Ruby, Ajax that you don't get with runrev is
the following.
1) Re-usable LIBRARIES.
Honestly what I have read recently on how revolution is so much
superior to Director or Java is just a *BIG* joke. Agreed, revolution
let you write stuff rapidly.
Marielle,
Most of us know, you have a running feud with those at RunRev. If you
aren't happy with the tool, then just don't use it. It's that simple.
Perhaps there aren't as many libraries available for Transcript, but who
says using only reusable libraries is the only way to code quickly? I
Marielle-
Friday, March 17, 2006, 4:44:16 AM, you wrote:
2) Rich and easy to access documentation
If you want to use a java library written by somebody else, simple,
you get access to the API online and you know what method to call and
how. You don't need to know *anything* about the inner
On 17 Mar 2006, at 18:26, Mark Wieder wrote:
Marielle-
Friday, March 17, 2006, 4:44:16 AM, you wrote:
many Japanese management concepts such as Total Quality Control,
Quality Control circles, small group activities, labor relations. Key
elements of Kaizen are quality, effort, involvement of
Hi all,
I must have missed the fuse on this thread, sorry - I only caught it from
Mark's response to Kaizen - sorry, Marielle, I accidentally deleted your
list of concerns but have now a copy to review. Some of it Id like to
discuss off list.
Lets step away from the impending flames of
I agree with what you say, Mark, but I think it isn't the
whole picture. In the early 80s, a guy at a Japanese steel
company explained to me how his time was being taken up with
visiting Americans determined to learn the secrets of
Japanese TQC. He felt they were wasting their time. Not
Lynn Fredricks wrote:
Until Jacque
finishes her time travel stack, there isnt much that can be done with
history :-)
2006 will be a good year for Runtime as a company and Revolution as a
product platform.
Playing with the beta again, are you? ;)
--
Jacqueline Landman Gay |
Interesting topic.
I've probably logged over 30 trips to Japan since 1986. I once had the
good fortune to meet with a Dr. Sasaki, the father of computer science
in Japan for lunch. He was an original member of the ENIAC team here in
the US.
I mentioned to him that many years before, Japan
I had the pleasure of serving tiramisu
A gracious host, Richard G. is! Thanks for your full meal of a post as
well as your deserts.
Rich
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe
Marielle-
Wednesday, March 15, 2006, 5:22:34 PM, you wrote:
Simple: A method for outputting Java byte-codes equivalent to
MetaCard scripts has been designed, but implementation has been
delayed until the serious performance, compatibility, and
functionality limitations in Java have been
Hi Mark,
Marielle-
Wednesday, March 15, 2006, 5:22:34 PM, you wrote:
Simple: A method for outputting Java byte-codes equivalent to
MetaCard scripts has been designed, but implementation has been
delayed until the serious performance, compatibility, and
functionality limitations in Java have
Dan Shafer wrote:
With the caveat that I am hardly a Rails expert and certainly have not done
a lot of work with Rev on the server side either, let me see if I can
clarify my earlier point here. I know that what I'm going to say is probably
so trivial to many reading this thread that it will
Forgive the intrusion from a 'lurker', but as I've learned so much from
you all the last three months, it's time I gave something back.
I'm developing using Ruby on Rails on both Windows XP Pro SP2
(Knoppix) Linux simultaneously.
Rev works just fine with FastCGI. Fwiw, I'd be happy to set
Peter Elliott wrote:
Rev works just fine with FastCGI. Fwiw, I'd be happy to set up
some benchmarks and publish the results next week, if it helps.
That would be enormously helpful. Thank you!
If you come to RevCon West in June or Euro RevCon in November I'll buy
the beverage of your
Richard
Thank you for the kind invitation! Given that I'm writing these server
programs in aid of a certain well-known 12 Step program's online
activities, and that it's doubtful I'll be at either event, more's the
pity, please be advised you can Fed-Ex any kind of high-test
caffiene-laden
How about a tutorial on how to set up Rev to use FastCGI. For those
of us for whom a lot of these terms are totatlly new, it would be
great to be able to take advantage of some of these tools.
I know I'm already salivating at the possibilities of merge(),
something I just learned about on
On 3/16/06 10:13 AM, Richard Gaskin [EMAIL PROTECTED] wrote:
I would
enourage those interested in web apps grab Dr. Raney's mchttpd.mc and
play with it a while. It's a thing of beauty to just open the stack,
click the Start button, and call it with your browser.
Hi, Richard,
I am
Wally
As (your) luck would have it, we're working on exactly such a document
for the poor unfortunates who will inherit the servers once I've wrought
havoc on them.
This is pro bono stuff for the fellowship AFAIC, for keeping me sober
since 1979, so by all means, when it's done and
Wow Peter, great! As one of the lurkers who has been toying with
Revolution before taking a dive, this is indeed inspiring.
Thanks,
Michael
On Mar 16, 2006, at 7:44 PM, Collabyrinth VPN wrote:
Wally
As (your) luck would have it, we're working on exactly such a
document for the poor
Peter,
As a fellow 'coffee' drinker, welcome to the list.
We keep what we have by giving it away. works real well in this
environment too.
Easy Does It,
Tom
On Mar 16, 2006, at 7:44 PM, Collabyrinth VPN wrote:
This is pro bono stuff for the fellowship AFAIC, for keeping me
sober since
Jim Ault wrote:
On 3/16/06 10:13 AM, Richard Gaskin wrote:
I would enourage those interested in web apps grab
Dr. Raney's mchttpd.mc and play with it a while.
It's a thing of beauty to just open the stack,
click the Start button, and call it with your
browser.
I am beginning to step
Michael
Well, I was looking for solution to fasttrack an entirely different
project when I ran across Revolution. I've been running it on a
Groundhog Day WinBox, but it's dive-time for me, most certainly. This
list is also a very fertile group, I think, and that's helped immensely.
On 3/16/06 6:54 PM, Richard Gaskin [EMAIL PROTECTED] wrote:
The default port in mchttpd is 8080 -- on my Mac I use:
http://localhost:8080/
Woiks very good... cool.
Is there a tutorial about how to put this in action on my G4 that has a
static IP? I know that Apache would be the
Well, at least from the mc stack, you just run it and it seems to intercept
the call on the designated port. You can manually change the port in the
launch stack as well.
PRetty cool stuff.
On 3/16/06, Jim Ault [EMAIL PROTECTED] wrote:
On 3/16/06 6:54 PM, Richard Gaskin [EMAIL PROTECTED]
Richard.
I *certainly* don't disagree with your response, but I'm earnestly seeking a
description of how you'd go about building an app in Rev that is entirely
deliverable via a Web browser, which is, I submit, the definition of a Web
application. I think that was the original point/question.
Dan Shafer wrote:
On 3/14/06, Richard Gaskin [EMAIL PROTECTED] wrote:
But if the goal is to deliver the benefits of productive,
flexible systems, Transcript can prove quite capable in
ways that may surprise.
Richard.
I *certainly* don't disagree with your response, but I'm earnestly
And as long as MCRev web applications servers have been my best
incomes sources betwin 1997 and 200x, i just can add that Rev is,
before J2SE or PHP and behind Ruby on Rails, a real firstclass web
apps development platform. RoR is probably before Rev in about the
apps deployment framework
Richard Gaskin wrote:
It would be helpful is someone here has performance benchmarks on Rev as
a CGI relative to Perl, Python, Ruby, and other server-side languages.
I don't have benchmarks, but Scott Raney once said that the load time of
the engine when used as a CGI was insignificant.
--
Richard Gaskin wrote:
All that said, there are two benefits to Ruby: most of the code you'd
need is already written, and as open source it's all freely available.
But while Ruby may have some advantages, that doesn't make using other
languages to generate DHTML interfaces impossible.
Le 15 mars 06 à 23:22, Chipp Walters a écrit :
Richard Gaskin wrote:
All that said, there are two benefits to Ruby: most of the code
you'd need is already written, and as open source it's all freely
available.
But while Ruby may have some advantages, that doesn't make using
other
Couldn't a person build a Rev app that runs continuously, interpreting
information that comes in a various ports and returning the appropriate html
data as needed?
I mean, Rev can operate as a server. So, as long as you are willing to write
in all html formulating, it should be doable.
http://istream.homeunix.com/insead/index_en.html
;)
Le 15 mars 06 à 23:59, Jonathan Lynch a écrit :
Couldn't a person build a Rev app that runs continuously, interpreting
information that comes in a various ports and returning the
appropriate html
data as needed?
I mean, Rev can operate
1 - 100 of 129 matches
Mail list logo
