1. putting RIA into Euphoria
- Posted by Thaddeus Quay <ThaddeusQuay at gmail.com>
Jun 08, 2007
-
Last edited Jun 09, 2007
In http://www.listfilter.com/EUforum/m14305.html I mentioned a new direction for
Euphoria, and that is, targeting Euphoria towards Rich Internet Applications, or
RIA. I find it quite a coincidence that this acronym represents the last three
letters in "Euphoria". I don't care for superstition, but what better way to say
that it was "meant to be"?
Anyway, Euphoria has been plagued, like many other languages, with the GUI
problem, where it is difficult to make an application work the same, in a
visually-appealing manner, across platforms. I am aware of the various
solutions, as well as the fact that none of them are truly adequate. The one
thing which pretty much everyone appears to have ignored, is that, despite their
problems, incompatibilities, and general fickleness, web browsers make for a
usable, although not great, cross-platform GUI.
What I would like to see, are application servers, written in Euphoria, which
act as proxies to the Internet, and which communicate with the user through web
browsers. For example, I could have my own server, which is a Euphoria program
and a database, running all the time. I would call up a web browser, whether on
my computer, or on any other which is connected to the Internet. I type in the
URL for my server, get the main page, type in a password, and am then presented
with whatever I've specified as the default start page, which could be as simple
as Google's main search page.
I type some text in the search bar, my server brings back a results page, which
could be from my own database, from the Internet, or a mix. Instead of search
text, I could also type instructions, like I would at a dos/linux command prompt.
The server would execute the instructions, against its database, by getting
pages from the Internet, or a mix, and presenting a results page. In either
case, the results could be text or images, either of which could have come from
the local database, from the Internet, or generated by my server.
On a more complex level, the server could generate Flash or Silverlight, thus
providing a richer method of interaction. On an intermediate level, it would be
quite acceptable to have the server generate a still image, for every interactive
result, along with a client-side image map embedded in the HTML. Many types of
applications could be ported by such means, although the resulting interaction
wouldn't be quite as smooth as in standalone applications, such as when you need
to scroll through a large document. However, creating such things using EuphoRIA
would be far simpler than using AJAX, which can easily push browsers to their
breaking point.
Notice above my use of "EuphoRIA" to indicate a program written in Euphoria,
which interacts with the user through a web browser, and which interacts with the
Internet. The latter can easily be accomplished through the use of libcurl, or
even more easily, through system calls to cURL.
Additionally, EuphoRIA programs could be augmented by using URL-based includes,
which would come from code that's put up in journal entries, in a system such as
LiveJournal, where people can review and improve on the work. Mix the ideas of
social networking, the Euphoria code archive, and Euphoria's micro-economy to
create a vibrant community of developers, which generates quality code and whose
peer-review is near-automatic, as demonstrated daily through people actually
using the code in their own EuphoRIA systems.
I wanted to make this more detailed, but I'm pressed for time. I hope that I've
gotten across the basic ideas which could quickly and significantly increase
Euphoria's visibility.
2. Re: putting RIA into Euphoria
- Posted by Bernie Ryan <xotron at bluefrog.com>
Jun 08, 2007
-
Last edited Jun 09, 2007
Thaddeus Quay wrote:
>
> What I would like to see, are application servers, written in Euphoria, which
> act as proxies to the Internet, and which communicate with the user through
> web browsers. For example, I could have my own server, which is a Euphoria
> program and a database, running all the time. I would call up a web browser,
> whether on my computer, or on any other which is connected to the Internet.
> I type in the URL for my server, get the main page, type in a password, and
> am then presented with whatever I've specified as the default start page,
> which
> could be as simple as Google's main search page.
> etc. etc.
Sounds like CGI which Euphoria is already used for.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
3. Re: putting RIA into Euphoria
Bernie Ryan wrote:
>
> Sounds like CGI which Euphoria is already used for.
No. In CGI, a Euphoria program is called by a server, like Apache, which then
returns a web page, completing an operation which is usually stateless. A
EuphoRIA program is inherently stateful, because it would use its database to
remember what has happened. Also, a EuphoRIA program would run locally, thereby
not requiring all of the hassle of CGI (as in, existing on another machine, and
the testing which is then made difficult due to that fact, etcetera). Finally, a
EuphoRIA program would be persistent, allowing continuous computation and
fetching of web pages, where my commands could be queued, with results coming in
asynchronously, as opposed to the usual synchronous human usage of the Internet
through a browser.
4. Re: putting RIA into Euphoria
Thaddeus Quay wrote:
>
> Bernie Ryan wrote:
> >
> > Sounds like CGI which Euphoria is already used for.
>
> No. In CGI, a Euphoria program is called by a server, like Apache, which then
> returns a web page, completing an operation which is usually stateless. A
> EuphoRIA
> program is inherently stateful, because it would use its database to remember
> what has happened. Also, a EuphoRIA program would run locally, thereby not
> requiring all of the hassle of CGI (as in, existing on another machine, and
> the testing which is then made difficult due to that fact, etcetera).
> Finally,
> a EuphoRIA program would be persistent, allowing continuous computation and
> fetching of web pages, where my commands could be queued, with results coming
> in asynchronously, as opposed to the usual synchronous human usage of the
> Internet
> through a browser.
So, like Ajax? Which has the quality of having Javascript built into almost all
browsers?
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
5. Re: putting RIA into Euphoria
Jason Gade wrote:
>
> So, like Ajax? Which has the quality of having Javascript built into almost
> all browsers?
AJAX helps with state, but is not really local, given that huge amounts of code
need to be downloaded. I read recently something about MS scaling back the new
AJAX-based redo of Hotmail, because it was too slow for dialup modem users, due
to the size of the code. A EuphoRIA program wouldn't have that problem, because
all of the code would reside in the server. Also, DHTML and Javascript are poor
substitutes for a real, fast language like Euphoria, and their use tends to break
browsers by pushing the envelope of what's possible too far. Finally most of the
time, the user would be on the same machine as the EuphoRIA server, thereby
experiencing a fast response with anything that didn't require access to the
Internet, such as when the EuphoRIA server is acting as a word processor.
6. Re: putting RIA into Euphoria
Jason Gade wrote:
>
> Thaddeus Quay wrote:
> > Also, a EuphoRIA program would run locally,
...
>A EuphoRIA program wouldn't have that problem,
>because all of the code would reside in the server.
Well that makes things all a bit clearer...
SCNR,
Pete
7. Re: putting RIA into Euphoria
Pete Lomax wrote:
>
> > Thaddeus Quay wrote:
> > > Also, a EuphoRIA program would run locally,
> ...
> > > A EuphoRIA program wouldn't have that problem,
> > > because all of the code would reside in the server.
>
> Well that makes things all a bit clearer...
I used "local" and "server" interchangeably, because a EuphoRIA program is a
true peer, both a client and a server. One way to look at it is to have your own
server, which can offload lots of work from the traditional server tied to a
domain name.
8. Re: putting RIA into Euphoria
Hello Thaddeus,
your EuphoRIA vision sounds very interesting to me. So what do you think
are the first concrete steps to success, that we, the Euphoria programmers,
could/should take?
Regards,
Juergen
9. Re: putting RIA into Euphoria
Thaddeus Quay wrote:
>
> Pete Lomax wrote:
> >
> > > Thaddeus Quay wrote:
> > > > Also, a EuphoRIA program would run locally,
> > ...
> > > > A EuphoRIA program wouldn't have that problem,
> > > > because all of the code would reside in the server.
> >
> > Well that makes things all a bit clearer...
>
> I used "local" and "server" interchangeably, because a EuphoRIA program is a
> true peer, both a client and a server. One way to look at it is to have your
> own server, which can offload lots of work from the traditional server tied
> to a domain name.
Hello All,
I just wanted to comment on this post here, cause it seems to me, like it's a
combination of two things that exist in the Ruby Language World. One being the
fact of Ruby on Rails, which is an MVC type system, (Model, Viewer, Controller
for thoes who don't know what MVC is), where all the framework has been created
to translate data from a Model, and interact with it, without having to worry
about the backend Database. Which makes it quite easy to work with databases of
any kind, and swap between them. The other part, is similar to RubyWebDialogs
which generates a User Interface by means of creating a Web Server for the
browser
to be pointed to.
Now as much as AJAX has been spouted in this, for reasons of major code issues,
one cannot dismiss the fact, that implementing AJAX with a Web Server type
application, is not without merit. While I wouldn't program the entire
application logic in AJAX, I would utilize it, to allow Controls to interact
with
the main Application. Example being, instead of using Full Scale images, with
image maps to create the User Interface, AJAX can be used to create Native
Controls
to do the same thing.
A push button can be used to send the command to the server, to interact with,
the
forms can retrive the data, and send it via AJAX. This eliminates alot of the
overhead needed to send Full HTTP Headers for each request, and therefore
increase
reliability, and response time for over the internet actions. As was mentioned
before, with the fact that you can run the Application, and access it from
anywhere,
AJAX can improve the response time, and make it as though the Application was
running
right on your own computer, no matter where you accessed it from.
Just my two cents, for following this nice little convo. Trust me, I've already
looked into this possibility in my own programming, with Ruby. It's an
interesting
idea, but work needs to be done to incorperate AJAX to make it worth while.
Mario Steele
Euphoria/Ruby Programmer
10. Re: putting RIA into Euphoria
- Posted by Thaddeus Quay <thaddeusquay at gmail.com>
Jun 09, 2007
-
Last edited Jun 10, 2007
Juergen Luethje wrote:
>
> your EuphoRIA vision sounds very interesting to me. So what do you think
> are the first concrete steps to success, that we, the Euphoria programmers,
> could/should take?
Thank you. First, I need to make an important distinction. I intentionally
referred to Euphoria-based, RIA-style programs as EuphoRIA systems or programs,
instead of as EuphoRIA, because EuphoRIA is not a monolithic product, but rather
simply the umbrella moniker covering the usage of Euphoria in a RIA manner, where
we write Euphoria programs which interact with users through web browsers. There
can be many different EuphoRIA systems/programs, written by many different
people, for many different purposes. As a shorthand, I've come up with
"EuphoRIAS" to mean "EuphoRIA Server". This makes sense, because I'm saying that
a particular program or system is written in Euphoria, with the purpose of
Serving up Rich Internet Applications. It's not perfect, but I'll use this until
someone invents a better way of distinguishing the overall concept from a
particular instance. What I think needs to be done is as follows.
1. Create a base EuphoRIAS. This is the absolute minimum that needs to be
installed by someone who does not have any prior exposure whatsoever with
Euphoria, and would consist of the following items.
1a. A Euphoria interpreter, standard issue or modified. I prefer the one
officially coming out of RDS, because then the EuphoRIAS should be much easier to
debug. The source for the interpreter should also be included, if for no reason
other than simply to assure people that this is a truly open project.
1b. The EuphoRIAS' code, in Euphoria. This should be in human-readable form, so
that people don't fear their machines will be damaged or taken over. I
understand that this is not the norm, and most people are usually happy to
download and run executable code directly, but knowing that the EuphoRIAS runs
directly from source, will, in general, make people feel safer, therefore
potentially increasing the spread of EuphoRIA. More importantly, this allows for
easier updating, as I will cover in section 2.
1c. A database. This should be as simple as possible, because the EuphoRIAS is
almost entirely responsible for its own maintenance. This is not an exercise in
programming for the user, and therefore, the user should have the absolute
minimum of direct contact with the database. EDS should be used, unless there is
some sort of definite, must-have advantage to something more complicated, like
SQL. I though of XML, but that would likely be slower than EDS, and would only
really serve to give people the warm feeling of their data being "open", which
could easily be accomplished through an XML export option. Regardless, the
purpose of the database is to store tables, which, at a minimum, would retain
state and transaction information. For instance, all Google searches could be
remembered, as well as the last 100 changes to the text document currently being
edited, etcetera. Additionally, there could be a dictionary table for spell
checking, a table with a list of all cities in the world, or any other table
necessary for allowing the EuphoRIAS to fulfill the purpose for which it was
designed. A base EuphoRIAS would initially have very little in its database.
1d. cURL. This is the program which allows the EuphoRIAS easy access to the
Internet. I know that there is a Euphoria wrapper for libcurl, but it is likely
incomplete and/or outdated. Besides, I personally don't like having to include
libraries, because of all of the effort of wrapping, and then, the potential
problems of memory usage, such as leakage or conflicts with the main program, or
whatever. I would prefer to simply construct a cURL command line, and then just
call out to the OS to execute it. So, my current choice is cURL, but I
understand that there may be some performance or other advantages to using
libcurl.
1e. A means of accessing the EuphoRIAS from a web browser. For local usage,
this is easy, but for remote use, such as from an Internet cafe, accessing a
user's EuphoRIAS, which is running all the time on their home/work computer,
there would have to be an IP number, which is probably dynamic. My understanding
is that, at least on Linux, this can be easily gotten through DHCP, but I don't
know the method for Windows. A more complete solution is to have the EuphoRIAS
determine the current IP number every time it is started, and then immediately
transmit that number to a website, where it will be assigned to a URL which is
easy for the user to remember. For example, my URL might be
http://www.rapideuphoria.com/EuphoRIAS/ThaddeusQuay which would always have my
EuphoRIAS' current IP address, and would automatically redirect me to there.
Additionally, this would make it easy to track running EuphoRIAS from all over
the world, and could be used as a simple means of establishing peer-to-peer file
transfer, including instant messaging and distributed computing.
All of the above is placed into a zip, downloaded by the user, and unzipped into
a folder of the user's naming and placement, without any further installation
required. The user opens the folder, and runs the main program, whatever that
may be called. The main program runs in the most minimally-visual manner allowed
for that platform, with no user input or output, because all user interaction
will be through the web browser.
As far as the user is concerned, after this minimal effort is over, all further
interaction with the EuphoRIAS is just like accessing a website. The user opens
their web browser, and gets the EuphoRIAS' start page using whatever method was
chosen through 1e, above. The start page merely allows them to login, after
which they can have some level of access to the EuphoRIAS' database, but more
importantly, access to external code, as follows.
2. Create Euphoria code which does something useful within a EuphoRIAS. There
was a recent discussion here about what to do with the micro-economy, given that
Euphoria was now open source, or something to that effect. It seems that the
code archive, although still certainly useful, has reached an evolutionary dead
end. In the archive, people need to trudge through lots of code, most of which
is either outdated, or was created for some specific, hobby-level purpose. This
is a daunting task, even for experienced programmers, especially for those who
are new to Euphoria, regardless of the micro-economy ratings. Even when suitable
code is found, it needs to be analyzed for naming conflicts, debugged for the
situation at hand, and finally, the "includes" are pushed onto the finished main
program. EuphoRIA could make a major leap here by allowing the EuphoRIAS to pull
the "includes".
For example, create an account on LiveJournal. Post pieces of code, in
human-readable form, as journal entries, with a limit of something like 65KB
each. People come around, see your code, and write comments about it, which
could lead to you changing the code. Minor changes could be edits to your
original journal entry, whereas major changes would require a new journal entry,
with the old one being deprecated in some fashion, probably with a simple link to
the new one, indicating, to any EuphoRIAS' future accesses, that there is a new
version with substantial changes.
These journal entries are the "includes". The EuphoRIAS would pull them in, as
upgrades. In the last paragraph under 1, above, I mention that the base
EuphoRIAS allows access to external code. Well, this is it. Said access is like
the Synaptic package manager, in Linux. The EuphoRIAS seeks out code
repositories, which could simply be accounts on LiveJournal. It then goes
through each account, looking at each journal entry, which represents a single
procedure/function. It makes a list of URLs, but only for those journal entries
which represent the latest version of a procedure/function. This list is then
placed into the EuphoRIAS' database, as a table, and presented to the user,
through the web browser, as a list of checkable elements. The user decides which
ones should be downloaded. The EuphoRIAS then proceeds to update itself,
resolving any dependencies, along the way, just like Synaptic does.
Now, here's the real trick. The EuphoRIAS writes out, to the hard disk, a new
version of itself, updated with the newly-downloaded functions and procedures
(the pulled "includes"). When this is complete, the EuphoRIAS runs the updated
copy of itself, and then either stops itself, or is stopped by the updated copy.
The updated copy is now the user's one and only EuphoRIAS, which proceeds to push
a page to the user's browser, stating that the upgrade was successful. If
something goes horribly wrong, it's easy to roll back to the previous version, as
that is still on the hard disk.
I realize that this doesn't completely answer your question. I'll try to
assemble a detailed usage example, so that you might be able to extrapolate more
of what would need to be done to make this a reality. In the meantime, feel free
to let me know what you think of the details, so far.
Lastly, I want to say that RDS has done a good job with Euphoria and the
RapidEuphoria website. Also, I don't mean to infer, from anything I have to say
about EuphoRIA, that RDS needs to change anything. No. EuphoRIA obviously needs
Euphoria, but no changes need to be made to either Euphoria or the RapidEuphoria
website, in order for EuphoRIA to exist. EuphoRIA represents a RIA-based
evolution of Euphoria, and it can certainly coexist, in parallel, with everything
that RDS is doing.
11. Re: putting RIA into Euphoria
- Posted by Thaddeus Quay <thaddeusquay at gmail.com>
Jun 09, 2007
-
Last edited Jun 10, 2007
Mario Steele wrote:
>
> Ruby, Rails, MVC, AJAX, databases, user interface,
> image maps, native controls, response time ...
See http://www.listfilter.com/EUforum/m14344.html for a better explanation of
EuphoRIA. As far as your specific points, I'll try to answer them here.
I have looked at just about every language available today, so I have some
familiarity with Ruby and the separate Rails Internet-based framework. I don't
really understand how MVC applies to EuphoRIA, but some of the same concepts
could probably be used. Regardless, I am not against AJAX, but I do think that it
is unnecessarily complex. Web browsers were not designed to work like desktop
applications, and it will be another few years before AJAX is to the point where,
if not easier to implement, at least it won't cause the browsers to crash so
often.
EuphoRIA can certainly implement AJAX, but remember that there is at least one
main difference between standard RIA and EuphoRIA, and that is, most people using
EuphoRIA, most of the time, will be accessing a EuphoRIAS locally. This means
that bandwidth is not an issue, because the transmission of large, generated
images would appear to occur almost instantly. So, why bother with complex AJAX,
in the situations where a simple, client-side image map would suffice?
The bandwidth issue leads to another difference between standard RIA and
EuphoRIA. AJAX is usually designed to minimize data transfer, but when your data
and server are both local, you now have the option of switching to simpler
interface methods, ones which, unlike AJAX, won't sometimes cause strange things
to happen, due to discrepancies between what the server sees and what the server
thinks you see. I have been able to confuse various RIAs, both purposely and
accidentally, where the server's view of the data was grossly out of sync with my
view, thereby causing strange situations, some of which lead to data corruption.
This kind of thing is becoming rare, but still, why bother with the possibility
when there are ways to obviate it?
Standard RIA is getting out of control. People are using it, all over, for lots
of important reasons, yet giving little thought to the fact that their data,
usually unencrypted, is now in the hands of large corporations. Also, before AJAX
is even mature enough to work without problems, Google, among others, is going to
the next level, where you can work offline, because the server and a database
with your changes will exist on your own machine. So, when you get off the plane
or the mountain, you connect to the Internet, and Google's servers will sync
their version of your data with whatever changes you've made. I can just imagine
how badly this will work, initially, especially for email. Anyway, EuphoRIA has
already solved these problems, because you are always in control of your own
data, and you don't have to sync anything, unless you are working on some kind of
group project.
The only thing I can see that standard RIA has over EuphoRIA is the magic of
"zero install". This is important for public computers and heavily-controlled
work computers, but, for most people, I imagine that it wouldn't be a problem to
install something small, which is easily updated from human-readable
repositories. Besides, standard RIA doesn't work when the Flash player on the
computer at the Internet cafe needs to be upgraded.
EuphoRIA doesn't need its own plugin. Combine that fact with AJAX kept to a
minimum, and it's obvious that any EuphoRIAS is unlikely to strain the browser.
EuphoRIA opens up many possibilities, which are difficult to implement using
standard RIA. I've only scratched the surface. Take a look at http://gliffy.com
which is a useful, interesting, high-end Flash RIA. That could be done in
EuphoRIA, even generating the Flash, but with the added feature of extensibility
through community interaction. By the way, Gliffy was created using
http://www.openlaszlo.org which allows you to "program" in XML, and then output
to either Flash or DHTML. OpenLaszlo is cool, but rather large and complex, even
for casual use.
Finally, the "Rich" from "RIA" doesn't need to mean pushing the browser to its
absolute limits, by including every little thing that can be found on desktop
applications. Most of the time, I want results, without a cinematic experience
attached to their production. EuphoRIA provides for a huge amount of server-based
processing to be offloaded from websites to a user's computer. This allows for
more speed and more user control of data, and for most people, those will be, at
least initially, more important than having the fanciest possible interactive
elements. Later, as it grows, the EuphoRIA community can move into AJAX, Flash,
Java, Silverlight and whatever other means might exist to give a deeper user
experience. Take a look at the following two Google TechTalks, where one covers
why it's often better to have less choice, and where the other covers, towards
the end, the AJAX difficulties in the creation of the Yahoo! Pipes service.
The Paradox of Choice - Why More Is Less
http://video.google.com/videoplay?docid=6127548813950043200
Pipes: A Tool For Remixing the Web
http://video.google.com/videoplay?docid=8569811679113799879
12. Re: putting RIA into Euphoria
> Thaddeus Quay wrote Etc.
Thaddeus:
Instead of these long explainations of EuphoRIA,
Why don't you simply write a demonstration version of
your program so we can all understand the point you
are trying to make.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
13. Re: putting RIA into Euphoria
Hello Thaddeus,
you have painted an interesting picture of EuphoRIA. However, in order
to be able to understand what it actually means, I need -- like others
here on the forum -- *specific* information.
Every long journey starts with the first step. So what is the most simple
EuphoRIA project that you can think of? What is needed for it? Until now,
I understood that the following is needed:
- Euphoria, including EDS:
We have that already. 
- A web browser:
Can any of the existing web browsers be used, or is it necessary to firstly
build a special web browser, that can interpret and execute }}}
<eucode> </eucode>
{{{
tags which are embedded in HTML tags?
- A web server (might be local):
Can any of the existing web servers be used, or is it necessary to firstly
build a special EuphoRIA web server?
- What else is essential for the most simple EuphoRIA project?
Regards,
Juergen
14. Re: putting RIA into Euphoria
Juergen Luethje wrote:
<snip>
> - A web browser:
> Can any of the existing web browsers be used, or is it necessary to firstly
> build a special web browser, that can interpret and execute }}}
<eucode>
> </eucode>
{{{
> tags which are embedded in HTML tags?
<snip>
Ooops. I wanted to write:
"a special web browser, that can interpret and execute [eucode] [/eucode]
tags".
Since I used angle brackets to surround the tags, they were interpreted by
the forum software.
Regards,
Juergen
