Re: putting RIA into Euphoria
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.
|
Not Categorized, Please Help
|
|
