AltME groups: search

well, and if there is not enough of nodes? While I would be able 
to reach RS directly using web-address (catalog), may RS fail? Or 
will your node contain few basic service sites for e.g.?

the crash does not happen if I read a web page or start e.g. the 
desktop beforehand

A guess: the web site is probably running a /core version -- /view 
versions used to not work well in CGI environments (though that may 
have changed).
/core has no draw ability.

Question: <Unix Time>..   I found several functions on the web that 
show you how to create a unix-timestamp from a rebol time (now). 
 However, I am looking for the ability to convert a unix-timestamp 
back into rebol-time.  I started writing my own function but I think 
that leap-years might mess me up.  Anyone have any thought on the 
matter?

Little casio watches know all of this info (Year/month/day/time). 
 I suspect it is in a static table inside the watch.  I have been 
looking for something like this on the web.

The exp function calculates e raised to the exponent of the argument 
to the function. If you look on the the web page he is referencing, 
you will see that where he puts e -k, the -k is in superscript, indicating 
that it is to be treated as an exponent.

Is there some way to send the html of a web page to the Rebol 'browse' 
function without actually writing the html file?

I still think, that in his particular case though, implementing small 
web-server would be rather trivial task though. There are some examples 
available ...

Is there a web-server in e? To use rebol thru cgi-style api?

Need to build "Internet 2.0" concurrently with "Web 2.0" ;)

(The results could be stored after this, mayb, so that only popular 
questions have web pages generated with the results in them.)

So it needs a database, and a web interface to be able to make queries 
to that.

I'll write you privately, as we don't want it to be exposed too much. 
(Users are depending on it, and this goups is web-public.)

hm, sorry for that. Maybe altme web output should cripple the emails.

Temporarily made this group not web-public. I guess in a day or two 
we can switch it back. Not sure how it works.

Oops I  forgot about the web-public stuff!!!

Yep, this belongs in the Orca group, or rather on the Orca web site 
if you want to contact the author. I'm not developing Orca, Syllable 
is simply integrating it. Of course that means we influence it a 
little, but that's it

Interestingly, more than a percent of the hits on our own web site 
are from our native Syllable web browser

Just before the previous release four months ago, 0.6.2, we introduced 
automatic weekly builds of the entire system, and a bug tracker on 
the web. So this is the first release that we have developed under 
full bug tracking and weekly builds

We ported WebKit, Apple's web rendering engine, to Syllable to build 
a new browser. Our old browser was based on KHTML, the open source 
engine that Apple forked to develop into WebKit

* A new version of ABrowse. The web browser has been re-written using 
the WebKit engine, which is also the basis of Apples Safari web browser. 
The engine offers excellent standards support and very fast rendering.

    * A new version of Whisper, and the Contact address book is now included.

    * A large number of usability and user interface fixes, largely courtesy 
    of Anthony Morphett.

    * New drivers for the SysKonnect Yukon1 network cards & ACPI CPU 
    management and updated drivers for Radeon, GeForceFX, SiS and Trident 
    video cards, HD Audio, Intel & VIA SATA controllers and Realtek 8169 
    network cards.
    * The usual clutch of bug fixes and enhancements.

re:drag and drop, yes that is what I meant, ie drag from a host partition 
to a "virtual" Syllable dir   guess the easiest way to get graphics/sounds 
to Syllable is via email or a web page.The reason for this is to 
test the graphics/sound apps in Syllable but since it comes with 
no sound/video files is the only way to test

Is there a reason for the syllable group not to be [web-public]?
If it were [web-public], then non-Altme users could read it here:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-groups-index.r?world=r3wp

And you (or anyone) could refer to a previous post via a persistent 
URL.

I added the web-public key. How long does it take to turn up on the 
site?

Might inspire doc to finish the web console if you release it as 
the default web server :)

I use Cheyenne for my web portal .. works fine.

yes as an iso...if you click the link it brings me to a web page 
with jibberish on the screen as if its displaying binary data so 
I saved and changed the name removing the htm.

The third release of Syllable Server has been published. This is 
an important release, because it is the first one that focused on 
making the system actually usable as a server. A number of popular 
servers were added and configured, and also several innovative REBOL 
software stacks. Out of the imaginary box, Syllable Server is now 
ready for such things as accepting remote SSH log-ins over the network, 
running a web server on the Cheyenne REBOL server, running an FTP 
server and several more. Special attention has been paid to programmability, 
with support for developing Model-View-Controller web applications 
in QuarterMaster and networking applications with the REBOL/Services 
Service Oriented Architecture. The Genode Nitpicker windowing system 
is also included. Read the rest in the full changelog. An extensive 
manual was also written, which is easy to follow. As usual, both 
a BitTorrent download (preferred) and a regular download are available 
(80 MB 7-Zip archive). Please use the torrent if you can.

This release focuses on making the system usable for running a number 
of standard servers, and several innovative REBOL servers.


The development files of the system, program headers, static libraries 
and development documentation, were moved to a separate area in /system/development/ 
and are now shipped in a separate package. If you want to compile 
software on Syllable Server, you need to install and register this 
package. The development files need to match the system: you can't 
use a package of any other Syllable version. (You will also need 
to install the Developer's Delight package collection and possibly 
other packages.)


User directories were moved from /home/ to /users/. Resource packages 
are in the process of moving from /usr/ to /resources/. /resources/ 
is currently a symbolic link to /usr/ so that resource packages will 
work from both places during the migration.


Many fixes were made, including more fixes for the CUPS print server 
and GhostScript. Creation of extra user accounts is possible now.


Many packages were updated, including the Linux kernel, IPTables, 
the GCC libraries, OpenSSH, SDL and QEmu. DirectFB was not upgraded 
due to incompatibility with Links2.


CDRTools were included for burning CDs, and the NetCat networking 
tool and the Transmission BitTorrent client were added.


In addition to the Syllable-specific early initialisation scripts 
(in the early-init subdirectory of packages), the late initialisation 
scripts (in the init subdirectory of packages) are now also executed. 
Several more initialisation scripts from Linux From Scratch were 
also added. Some servers can be started with the LFS scripts, others 
with the Syllable scripts (this will be unified in later releases).


The OpenSSH server was configured and now runs by default. At the 
first system start, security keys are generated that identify the 
server.


A collection of well-known root certificates from Certification Authorities 
was added to allow OpenSSL-based programs (such as OpenSSH) to establish 
the identity of destination points for network connections.


A MIME-types database was added in /etc/mime.types that is used by 
many programs, such as web servers, to identify the MIME types of 
files based on their file name extensions.

Several REBOL software stacks were added:

- The REBOL/Services Service Oriented Architecture.

- The UniServe network server framework.
- The Cheyenne Apache-class web server.
- A CAPTCHA library.
- A MySQL network protocol.

- The QuarterMaster web programming framework, based on a Model-View-Controller 
architecture. By default, it's configured to run on Cheyenne.


- The TINY library for parsing text, abstracting data access and 
building templates of generic text formats (including HTML). This 
library is an original creation and targets both ORCA and REBOL.


Configurations, including initialisation scripts, were added for 
the OpenSSH remote access server, the CUPS print server, the BIND 
domain name server, the Apache web server, the RSync file synchronisation 
server, the SaMBa Windows-compatible file server, the INetUtils FTP 
server and the VSFTP FTP server. Several of these are not included 
in the system, but need to be installed separately (the system is 
prepared for them). The sshd, cupsd and initd servers are started 
by default.


S3Cmd/S3Sync was included, a tool for accessing the Amazon Simple 
Storage Service (S3) and synchronising files with it.


As a demo, the Genode operating system framework, its Nitpicker windowing 
server (built on SDL) and its demonstration programs were included.

Is it even updated through a web interface, or just through the REBOL 
client?

registration is via the web ...

You could play the snake, divide the Indians among themselves and 
run the Boa web server. :-) We have a build recipe for it

Many bugs were fixed, including several regressions from earlier 
releases. The window decorators don't destabilise the system anymore. 
The installation procedure is greatly enhanced with options to fix 
hardware support problems. The native web browser is replaced with 
Webster, based on a newer version of the WebKit engine. Many enhancements 
were made to standards support, leading, among others, to the ability 
to run QEmu - so now you can run virtual machines. The documentation 
was improved and several translations were added. Read more in the 
full release notes: http://downloads.syllable.org/Syllable/i586/systems/Desktop/0.6.6/README-SyllableDesktop-0.6.6.txt
ISO CD images, (VMware) emulator images, an upgrade pack and documentation 
are available from the download page: http://web.syllable.org/pages/get-Syllable.html
Extra software is available here: http://web.syllable.org/Syllable/downloads.html

There is someone running a public web server on Desktop - on his 
own web server in his own language

Dunno, at least this one is not business critical. A decade ago, 
Syllable's forerunner was already running as a public web/FTP/CVS 
server

the point of the host is not to start your own rebol, but to allow 
rebol to work in your stuff.  that, I think, should be emphasized 
within the documentation/web site when it will all be official and 
"a product".

as web server?

We're using SQLite in our own Syllable Desktop web browser, though, 
so it's even ported to Desktop and it would be easy to use our build 
system to compile it on Server

I demoed AltME on the conference and my CMS running in View, generating 
web exports of AltME

The web viewer of SF CVS is back

And Kaj, now honestly you can tell me (decide for yourself, as this 
group is web public), why some ppl (or it's actually just one person) 
blames you from demotivating others? I always wonder, how such a 
thing as REBOL can make core developers to leave? What do you think 
about the topic? (not neccessary belonging into vent)

Any time I am on AltMe is break time for me. Most of what I do with 
REBOL nowadays is parse and file manipulation, and neither of those 
have changed much in years. I don't need View - most of my code is 
non-interactive or web-based.

As for interoperability with other VMs, for now REBOL either has 
to go for the lowest common denominator (C interfaces) or the highest 
(Web Services or other networking standards). Either way ends up 
being slow and awkward because of all of the marshalling and object-model 
translation involved, but that could all be simplified by making 
LNS shims for their RPC infrastructure.

If you want to access a web app from Rebol

page: open login-url ; a rsp session is sent to you
page/locals/headers/set-cookie contains the cookie

page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
(cookie)]] ; where auth is your authentication string eg. "login=user&pass=mypassword"
you are now authenticated
and if you now what to access a page in the web app

page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]


where you need to use my modified http protocol that allows you to 
send cookies with read/custom

DEBUG: I'm I right that the newest version doesn't send a Rebol error 
to the client anymore? How can I re-enable this "feature" for non-web-app 
pages?

Web-Apps Login: Is the login page always presented as first page 
if a user isn't yet logged in and tried to access an other page directly?

Yes, in my experience, as long as the other page is in the web app 
directory. You can't even use an external CSS file in the directory 
until you log in, even if it is referenced from the login page.

Web-Apps Login: Is basic authentication supported? I have a situation 
where form-and-cookie authentication is awkward.

secured folder = web-app folder?

yes, <web-app>/public/

I went with a web app for the database connection management and 
authentication, but now I find out I need to support stateless clients. 
So, no persistent cookies. Help?

Web-Apps Login: Is the login page always presented as first page 
if a user isn't yet logged in and tried to access an other page directly?


It depends, if you're using the AUTH keyword in the webapp config 
bloc, that's true. If AUTH is not used, you can access every webapp 
resource directly, it's up to each RSP to manage the access rights 
strategy. That's how CureCode webapp works. It uses a  common filter 
script called from 'on-page-start to control access.

Because every web site running Cheyenne doesn't need RSP scripts. 
For example, softinnov.org is only using SSI (Server Side Includes).

I use Cheyenne as a reverse proxy. I think in this setup the HTTPS 
things is handled by the primary web-server, communication to the 
revers proxy is non encrypted and hence this setup should make it 
possible to use Cheyenne's RSP with HTTPS. Not elegant but it should 
do the job.

this being said, I will be using a cheyenne server for my brand new 
web setup, using remark to replace rsp completely.  So I will build 
a remark-mod shortly.

The last entry was probably the cause of some of the rare "RSP freezing" 
issues. I've stumbled upon it recently while making a demo of one 
of our web-based products using IE7 through a proxy.  By default, 
IE7 switches to HTTP1.0 when connecting to a proxy causing the extra 
CRLF bytes after POST data to appear.

Hi Doc. I am "porting" to 0.9.19 , the main thing that was causing 
causing the confusion since I didn't yet fully get it  was that "do" 
inside one of  another file that was "do-ed" didn't seem to use path 
relative to the that file but to web-app and before that wirtualroot 
property wasn't correct, I added the folder below root path.. now 
it works, and debug makes the whole output visible so I made it work 
better also.

I'm also planning to work (probably this summer) on a high level 
web testing dialect allowing to implement more complex use cases 
simulating the work of a real user.

That's very interesting and inspiring work. It's close to my own 
thoughts about a web app testing framework. You're very right, the 
main target should be the webapp API, not the UI. That's why I didn't 
invest in Selenium, I don't want to update scripts every time I change 
the UI without changing features.

I was thinking about making a low-level dialect allowing to simulate 
user actions in a web browser. Then use that dialect to build a higher 
level dialect (specific for each webapp) allowing to navigate inside 
a webapp, make complex actions and check the result, using a minimal 
set of keywords. I haven't wrote down, nor refined those ideas, but 
it should be able to give you (at the higher level) something like 
:  
[
	go site-assistant
	signup 
		login: "[user-:-test-:-com]"
		pass: "pass"
	check-page default-page
	add-new-website
		website: "rebol.com"
		registrar: "registrar"		
	check-result site-created "rebol.com"
	check-details website-form "rebol.com" "registrar"
	... 
]

Janko: I was planning for some very simple console-based reporting 
like: 
testing signup...
testing check-page...
### test KO : <error description>


But I'll be glad to join forces when both our approaches would be 
really usable. I didn't wrote any specification so far, I'm still 
at the idea stage. My main concern is to reduce the cost of testing 
regression for our biggest web-based apps in production.

now the fun part... building a new web site from scratch, using brand 
new technology  ;-)

As a result of an RSP script I want to return a new web-page that's 
on the file-system. I do it like this:

print read %payment/index.html


So far this works. What I need to do is, to insert some dynamic content 
into the read HTML file.

I'd say your RSP script should "be" the resulting web page; that's 
the normal way to generate dynamic pages. Why do you think of them 
as separate?

I did release my Hylafax web portal which I know a few people are 
using :)

I did build a web portal to my medical database .. but too busy to 
keep that going.  Have to learn a lot more jQuery ....

I see Cheyenne as a web-window to REBOL apps.

I build REBOL apps, databases, UIs, scripts. If I want some kind 
of web access to that, Cheyenne is key. I don't see Cheyenne as just 
another web server.

I don't see it anymore because now I use a Rebol client to access 
Cheyenne and not a web browser.

as Henrik said.. cheyenne was certanly rebol "web-window" for me. 
The day I tested and saw it can handle 300req/sec I switched to rebol 
for webdev.. there is no way I would use ordinary CGI to make webapps 
at this time.

Perhaps someone who has already written a kick-ass web server... 
:)

in mod_remark, all that can be forked to the task handlers will be. 
   remark will be using liquid for many things, allowing the task 
handlers to cache just about every CPU intensive task which doesn't 
need to be recalculated.  I expect it to be one of the fastest dynamic 
web systems on any platform.

I am using this site as a showcase for all of my work.  including 
web, visual arts, music, design, programming, etc.

Max, applying dataflows principles to a web framework looks really 
appealing, when will be able to see some demos?

I am aiming for sometime next week, just a few simple prototypes 
to explore how to handle the difference in  nature of web requests 
opposed to persistent  data.

query-string: Ah, the problem comes from a wrong rewrite rule for 
GET requests. I need to figure out how to handle this case.


That's what I like about web-stuff: There are so many possibilities 
and places that something can fail...

It's hard to define "mal-formed" precisely. If you strictly apply 
the RFC rules for URL, you'll find out that a lot of web sites are 
using "mal-formed" URL.

this is the latest release. from the web site.

even after you access a web page??

download and double click.... but  I'm working on mod-remark, so 
its not currently serving web pages...

yes! mod-remark has served its very first ever web page  :-)

Would a web hop interfere with virtual hosting?


I using a webhop to bring a domain through port 81 due to restrictions 
on 80.

It works on apache but I could not get it up on cheyenne...

Yes its listening to port 83 and I get the default web page (Cheyenne 
test page for now)

If I URL to the "mysite" dir (www.defaultsite.com/mysite) I  get 
vhost index page...

doc: might I do a RFE (request for enhancement)?


add a ./conf/  dir to cheyenne and load every file that ends with 
.cfg


this would allow us to distribute a configuration file with a module 
and provide setups per mod... its much more flexible to manage.

we could also have a setup for each vhost in our system, if that 
makes sense for the web admin.

I hate Apache config file. Because I hate having to read tons of 
docs to just "switch on" some app. Cheyenne's config file has never 
been designed to copy the Apache way, nor to be used by average end 
user. It's just a placeholder waiting to be replaced by a builtin 
web GUI allowing a simple, fast and straightforward way to manage 
the server. That has been the plan since the beginning and one of 
the main motivation for building Cheyenne. Unfortunately, I never 
had the required time to complete that goal yet, so I'm stuck with 
that, and that's also why Cheyenne is still at 0.9.x.

if the config GUI is web based... then it relies on the server actually 
working...  but I'm not trying to argue with you, just pointing out 
the fact that server configuration is usually much better handled 
in text and I think many admins prefer it.  the fact that everything 
in windows is GUI based is the most annoying aspect about it.

Well, I always thought that GUI was an improvement other text files. 
Cheyenne is suppose to work out of the box with a default config 
file. The admin web UI would be reacheable with http://server-ip/admin/
(just an example).

for myself... I would automatically turn off web-based config.  if 
not only for security reasons.

because they use PHP I'm guessing

 - the promotional web site uses some PHP, but the main site is all 
 REBOL.

Doc asked "Third party tools can be used to tunnel SSL, like stunnel 
or nginx. About RSP, does Cheyenne's RSP miss some features required 
by Qtask?"

Maarten might be best to answer this.


BrianH wrote ""because they use PHP I'm guessing" - the promotional 
web site uses some PHP, but the main site is all REBOL."


I want to rephrase this, to help make it clear.  Qtask is written 
100% in REBOL.  We call this the "service".  The website on the other 
hand (which has nothign to do with the service), uses PHP, becuase 
there are many tools that the Webmaster wanted to use in PHP.

Doc, RSP by itself.. I use a version which does set word capturing 
(do you do that?) and allows page inclusion and context injection 
with "captured" words on the subpage. Do you do that?


Otherwise, a lot of Qtask "the application"  is Javascript on the 
UI calling API services - RSP is of little use there. The main web 
site... I would actually oppose REBOL. Why spend time there on e.g. 
a shopping cart when you can take one of the shelf and spend that 
time improving the real product (the service/application)?

Doc, correct, but your approach works just as well for me. I explicitly 
force word passing because the web context is created in the RSP 
engine for the parent page.

Well, I've found RSP script pretty handy for web services too, generating 
dynamically javascript code or XML for AJAX requests.

in each of the above webapps, I have an app-init.r where I have defined 
myhost: blahblah ... so this is a global to be used by this webapp.

Unfortunately it looks like as soon as one web app is started by 
a visitor, then all webapps take the same value.  The value is not 
kept in the webapp's context

I've not had any issues before I used virtual web hosts .. and then 
my "global" app-init.r word spilled into the other web hosts

I was debugging some rsp code last night, and determined that the 
cause of my problems was that I was using some unitialized variables 
... but this wasn''t obvious because these variables had taken values 
from some one else's rsp session and web app.  To prevent this, apart 
from making sure I initialize my variables correctly, should I wrap 
my code inside an anonymous context ?

The resource url would have to be saved by the cheyenne api .. a 
web app can't save it.

how is the web based configuration page going?

alright. will attempt to upgrade to the latest cheyenne soon, so 
I can get back to some much needed web work.

Doc has a web control panel on the back burner ... so maybe that 
information will be there.