AltME groups: search

I'd like to hint focus on SQLite, inside it has its own key-value 
engine and now it has even Spatial (2 dimensional) R-tree indexes.

I know nothing. The only thing I know that SQLite is the tinniest 
and still rather functionally sufficient (complex) piece of DB code 
since the slice bread, cross platform. I hope we will make it a plug-in 
at least. But - I still want RIF. RIF as some standard aproach, upon 
which we can build RebolDB engine - then I don't hesitate to use 
one, because it will be lean and mean, and standard ....

Dunno what channel it was, but we were discussing possible native 
REBOL DB default inclusion. I could not remember one Java DB system, 
and now I found it, in case someone would be interested:

http://www.prevayler.org/wiki/


It is Java persistent values storage. Few years ago I looked at it, 
they claimed it can be implemented in some hundreds of lines of code. 
It reminds me in-memory RebDB, I wonder if they solve concurency 
somehow ...

BT: BDB is incompatible across versions, so that whenever you install 
something that uses it it needs to install its own version; it is 
bigger than things like sqlite which are much more powerful; and 
if you need a real thing just use postgres or mysql. BDB is just 
infinite bloat...

If we combine RIF, R/S and REBOL itself, we can get CouchDB in half 
a meg.

Gabriele; True and a good point.   (I miss RMS on the Vax).  I have 
faith that RIF will come, and RIF will rock.

Re BDB;  Found this on the cuil.com main page of a rebol search, 
by fluke of timing more than anything.

http://www.cs.unm.edu/%7Ewhip/   Jeff Kreis' libdb interface.  Works 
great with 2.7.6 and the freed load/library.  I just had to tweak 
Jeff's libdb.c to use my setup and to get around that pesky incompatibilty 
that I blame on Gabriele now  :)

cause i'm me and hum I do what please me that's what the concept 
of freedom is all about  :P

I've worked extensively for many months with a printing system for 
R2 and it works, but only in conjunction with Ghostscript. It's not 
possible to print directly to a postscript printer unless you want 
to adapt your output to each single printer to work around hardware 
bugs.

Currently I use the postscript dialect and do a preview with draw, 
but because of the difficulties of rotations, and translations, anything 
that involves those screws up the screen preview.

And scaling.

I was thinking about adding also a few other import filters for makedoc, 
pdf-maker dialect and View layouts, so something like this should 
be possible : write printer:// layout [...]

But as my free time is very reduced, I'll just release my lib with 
the scheme wrapper and let the community add layers upon that.

Once we have some sane documentation of the Windows printing model 
(read: the code you've written so far) it shouldn't be too hard. 
Not off-topis, btw: We can adapt your code to R3 and it might serve 
as the germination of a REBOL printing model.

You did. R3 plugins are to be a cross between a REBOL module and 
a library wrapper, and can be dynamically loaded like modules.

So, do you mean that with R3 to access a DLL I have to build (in 
REBOL and/or C) a plugin, then dynamically load the plugin and then 
the plugin will load the DLL ?

It's not that different from writing a script wrapper for a DLL now, 
just easier and more powerful (in theory).

Brian - it is not correct that no work was done. Carl told me few 
months ago, that plugins are some 80-90% done. They have forma API, 
they are just disabled. The plugin simply exports some info for REBOL 
to load and bind or something like that ...

Some info from Carl from the past:


The DLL access is very complicated code that is specific to every 
CPU and OS.The DLL access is very complicated code that is specific 
to every CPU and OS.

The problem with plugin is not the code itself, but the security 
of it.

If we can set security aside for a while, we can certainly have the 
method for it.
I think it is probably ok for 3.0 to make this statement:

If you want to use plugins, you can -- but, you will want to only 
use those from trusted sources. Do not execute unknown plugins from 
the web.

the complex part of the security model is some method of digital 
signing.

We could use a simple hash method, but the problem is with public/private 
certification.

What makes it complicated is that we must port the R2 encryption 
code to R3.
That project could take a few weeks.

security for plugin should be the same as for any fileacess no ? 
 and once again you are not supposed to use software you didn't documented 
before on it. I think there is more risk to damage you computer and 
data by simply surfing the net with IE 7  than using rebol.

after if you really want to bring a 100 %  plug security you have 
to make the plugins centralised done only by RT and with some asymetirc 
key control system to ensure no one have modified the DLL  betwin 
RT repository and the customer compurter

now in day to damge your computer you just need to log it to internet 
without firewall and anti-virus no even need to do anything your 
computer will be infected straight by a tons of worms

Pekr, I am glad to hear that some work has been done on plugins even 
though the module model isn't finished. We have discussed the security 
issues before in the blogs and their comments. The CPU/OS problems 
could be partly resolved by doing some CPU/OS-independent standardization 
of the REBOL side of the plugin model and let the OS side take care 
of itself. Defines in C headers and all that.

if RTmakesavailable  a signature bank for trusted pluging and when 
rebol runs a load-plug command this function send the name of the 
plug +  actual signature and compare it to what is stored in RT's 
bank but this mean offline using of plugs will be impossible

Hum I proposed long along when I was complaining about load/dll unfriendly 
shape to make a ported library repository wich you can find the standard 
libraries and the bridge to use them . the repository could be acknoleged 
by RT who will grant the lib is tested and safe download it and distribute 
is widely

now it depends of how do we considere the rebol sharings. what about 
those who want to build custom "plugins" based on official other 
libs but with only in it what htey need and not the whole thing (like 
SDK allows you to customise the VMrebol version you are going to 
share with your application...) Like rebolinforms the user when a 
rebol script is accessing external data it will be first  an information 
about the fact the script is about to load a plugin   and ask for 
user to continue or cancel. And if the user says yes then the answer 
is stored by rebol (in registry for example) so in next run the user 
is not bothered anymore. If the user is plugin to internet then rebol 
could check on the offical repository if the plug is safe or not 
this will give the user  an ensurance that the plug is safe.

Just tried Windows Speech Recognition on my Vista laptop and 2.7.6 
.. and it doesn't work.  I can dictate single letters into an area 
but not words :(  Hope R3 is better in that respect.

audio converts to text and send it to the curent text field as if 
it was a normal keyboard input ?

and it's not recognizing VID fields

He has stated that he wants REBOL's GUI to be more declarative, with 
structural and presentation cleanly seperated, and network access 
and services fully integrated. Sort of like HTML/CSS/HTTP done right: 
A REBOL browser. That is what he has been working on these last few 
months, what we have all been waiting for.

The idea of the REBOL browser is to replace the Viewtop paradigm 
with a webbrowser paradigm, because people will relate to that much 
more. You have a standard browser-like window. You enter a URL and 
get a "page" or a script run from that location displayed in the 
window. I mentioned earlier that I felt Carl was trying to restart 
webbrowsing. Carl's situation right now is probably right where Tim 
Berners-Lee was back in the early 90's as he was finishing Mosaic 
1.0. Carl will just be starting in 2008 with 2012-type web technologies, 
rather than 1994.

But we can already do one: Just 'do a complex VID script in the R2 
console, such as Devbase and see how fast it loads. Now do the same 
thing in AJAX.

Not that wide adoption and vindication wouldn't be nice... :)

AltME, DevBase and non-graphical batch scripts being the exceptions 
to server-side use, of course.

If the Rebol browser window does not fit in the browser window then 
adoption will be slow.  But there is some hope if we can do what 
the web does today (or better) in one language... that's golden and 
should increase the adoption rate.  I hope I will be able to get 
it in my work-place, that would make my decade.

Yup. There is a lot to learn there, and the number one lesson is 
this: they did it with what was there already, no plugins. If we 
want REBOL in web browsers, we are going to have to look somewhere 
other than Google for inspiration. Still, some of their recent behavior 
has some clues. Look at Gears - they are clearly recognizing that 
networks aren't reliable or fast enough to count on consistency. 
That's why they are promoting local storage.

In general, languages like Erlang handle unreliable networks with 
redundancy, and it can do that because it is a functional language 
with no assignment. The state needed to answer a question is passed 
with the question. That way you can ask the same question multiple 
times and get the same answer every time.

Still, Erlang's advantages are more from the OTP system than the 
Erlang language, though the no-assignment language with lightweight 
process concurrency and message passing makes it easier to implement 
something like OTP.

REBOL's statefulness and heavyweight processes make this kind of 
redundancy more difficult, but it can be done.

Maarten's stack was based upon Chord implementation. But he mentioned 
even more interesting stuff. IIRC, he also said it is already running, 
and once proven, he will release it.

Interesting .. and who owns the IP?

Graham, sometimes you don't want to see, and sometimes you don't 
want to wait.

I am finishing S3 as we speak (this week) and I hope we'll release 
it to the community as open source. Done right though - visible in 
the right places etc.

Chord: the real testing got stalled, I hope to return to it. I managed 
to express it in terms of a few functions. So if you can define those 
in REBOL (I did them using Rugby), and my implementation works... 
you can rebuild from the top down.

Will: done and working. Needs to be documented.

I want to pull a couple threads together for comment - the REBOL 
browser concept and the cloud/services parts such as S3.  I think 
there is great potential in delivering an environment that can bring 
rich network applications to the desktop but that support development 
without the limitations of the web browser/html/ajax technologies. 
 It can be less of a "browser" and more of a UI to services platform 
in my view.  Trying to shoehorn it into a web browser just because 
it is common is a mistake I think.

At the same time I do worry that a grand plan such as a REBOL browser 
is putting the cart before the horse, R3 as the base needs to be 
done and delivering on its functionality promises first.

To me it appears as if (and BrianH has stated this too), that the 
REBOL browser has presented Carl with a range of low-level issues 
that need to be fixed before he can move on. He's attacking the issues 
at both high and low level, by exposing R3 to real-world application 
development and seeing where R3 falls through. Some new functions 
in R3 are indeed made because of requirements from real-world R3 
standard libraries like VID3, such as DELECT.

He probably views it as much more expensive to correct R3 afterwards, 
and I think VID3.4 has profound changes in R3 just like Unicode had, 
so it's very important to get that right.

It was the lack of easy acess to S3 that caused me to finally bail 
from Rebol.  And it's still getting discussed..in PHP you can drop 
in a S3 class and be up and running in 5 minutes.

Face it, a language with no community is no language. And by community, 
I mean > 10000 daily users.

The shame is, Rebol is a great language.  Personally, I blame the 
license... the world changed, and failing to change with it is obscurity 
doom.

Face it, a language with no community is no language

 I wouldn't judge REBOL's adoption rate purely by the number of people 
 who regularly post in this world. I receive a lot of email from folks 
 using stuff I've written in their day-to-day jobs and they don't 
 post here or to the mail list ... I've even spoken to a few startups 
 who are going into business primarily on the strength of REBOL and 
 "time to market". Whether a "killer app" will ever be REBOL-based 
 is the big question ...

carl does rebol more for fun than for profits and since he gets fun 
and new ideas he want to build in rebol  there is no way rebol dies 
...

and rebol is intemporal like all languages. But yes we can say it's 
unknown and that's in my opinion a pitty.

What solutions we have to make rebol better known ? hum .... vast 
question and many ways to answer it

better known means more visibility more people claiming they use 
rebol because it's the best and nothing else ...

now you have several scripting languages and most of them are a "success" 
 because of their easy interoperability like lau or VB script...

and some other are succes because of their specialisation like PHP 
 wich outside a web server can't exist

and some other because simply you don't have accès to the source 
code like java (yes I know ....)

but the least we can say it that Carl is not so wrong in his vision 
because the need to extrapolate the hardware and the software is 
a more and more a need in software making industry those20 past years 
you get a lot of  scripting languages created

With out the community we have here I would not get too far with 
REBOL. Most of the apps I try to make can not be done out of the 
box without a lot of expertise and code add-ons that I get from you 
guys. For a novice reboler the community is essential...there really 
is no other source.

Hear hear!   hear, all ye good people, hear what this brilliant and 
eloquent speaker has to say!

The world has moved on. The browser is THE client, everything is 
moving into the cloud, and will continue to do so, and apps need 
to be mobile (read work on iPhone).

Terry, I'm still convinced that the whole "the browser is the client" 
thing will implode. It's just the wrong concept. You just have to 
many parts, protocols, plug-ins, versions, etc. involved to get it 
ever secure and reliable.

And I don't even own a Mac.

I don't think they're tyring to move away from the browser so much 
as trying to bring the desktop towards the browser... probably just 
because they can.. and I don't believe those technologies will get 
much traction.. especially compared to the browser.

I said it xy years ago, that it will happen. Nowadays browser is 
considered being "universal app container" ... the strange thing 
is, that while it provides crap speed (even with AJAX) compared to 
native apps, ppl are forgivable here. But - in order for browser 
to keep its chances, we need to keep the standards. Looking at W3C 
and all its MLs, I wonder how cross platform, cross browser support 
goes. There are technologies for multimedia like SMIL, etc., SVG 
- crappy supported.

And now we can see Google trying to keep their own agenda - moving 
ppl to Gears ... which has nothing in common with standards - it 
is linking ppl to use their services .... and off-line app support? 
There are some first tries, but that is it - just only tries - no 
standard for off-line apps. We recently collapsed our CRM system, 
because thinking that today's world is fully on-line, is wishfull 
thinking. So we are developing off-line plus sync ...

To much emphasis here is spent of technology .. and very little on 
solutions... like S3 support, API mashups blah blah blah.

The greatest killer app the world has ever seen could very well be 
built using Rebol, which would generate a massive following overnight. 
However, the killer app itself will be about an idea.. not something 
special Rebol offers, or any other language for that matter. When 
it boils down, all languages are pretty much the same. It becomes 
a religious thing and a preference.  There's a strong tendency in 
this biz for developers to stick with what they know, even if the 
alternative is 'better' (whatever that means)

Terry: browser... iPhone.... Safari. iPhone apps are a lucrative 
niche or a nice add-on (I have an iPod Touch so I know what I'm talking 
about..., and am in the process of getting an extra Mac for -among 
others- writing IPhone apps for fun).

Apple's App Store is doing for software what eBay did for auctions 
... it's a brave new world when I can buy an 'app' for $1.99 and 
2 mouse clicks. Cell phones and the software that runs on them is 
where the growth (and future) is.

The browser as the launch platform for applications has always been 
an interesting idea. The fundamental problem of the sheer complexity 
of it can be solved with R3. If done right, it can completely wipe 
the floor with browsers and AJAX. I think the problem is that we 
haven't been speaking in a language that people can understand, such 
as "browser", "web2.0" and "webserver", but instead "dialects", "VID", 
"Viewtop" and "X Internet" and people go "huh?".

Some things I believe are needed to do this right:


- Browser form factor. People are used to browsers, not Viewtops. 
What's always the first thing a complete newbie computer user uses, 
when wanting to do anything on the internet? A webbrowser. I don't 
want a desktop inside my desktop. There are tens of solutions for 
such things and they are almost all forgotten. Carl is doing the 
REBOL browser. When you fire up R3, you will get what looks like 
a webbrowser and acts like one. The concept has to work equally well 
for people like us, as well as 5-year-olds and 95-year-olds.


- Do apps that are similar to webapps, like GMail. That's a quick 
way to compare. Don't you think a 50k GMail look-a-like inside a 
REBOL browser running at native speeds would be _slightly_ impressive? 
Remember to say that you can serve 5 times more users with the same 
bandwidth. REBOL can help make raw numbers look better without much 
effort. Google would have to use it as a content platform. They have 
no other choice. :-) Chrome? What's that?


- Plugins suddenly are very flexible. You don't have plugins as in 
Firefox, but helper scripts that can enhance/change your browsing 
experience. 15k full screen document reader that prettifies plain 
text files? Sure thing. Blog posts presented in that would be much 
nicer to read. Out goes the PDF reader.


- Do apps that are completely out of the league of AJAX, such as 
multithreaded P2P systems. In fact, why not build P2P capabilities 
right in? Have different instances of the browser allow users to 
connect and chat, when they are visiting the same "Rebsite". It's 
sort of like going into a physical store and chatting with the other 
customers and you decide to exchange business cards. Initial contact 
without needing email. Do the same thing with chat support for an 
article that you bought at that  "rebsite". Current websites are 
almost completely anonymous. You don't feel you are entering a live 
community. Coded in REBOL/Services.


- Webpages are now REBOL scripts. In R3, scripts can be closed and 
encrypted, so you can't read the source and you can sell scripts 
and have them signed. The best you can do right now is some kind 
of code obfuscation.

- Windows, MacOSX and Linux version.


- "A webbrowser that directly supports OpenGL without obscure/limited 
3rd party plugins." Say that again in your head.


- It's very important that the public get to see that creating REBOL 
scripts for the browser is very similar to creating plain HTML pages. 
REBOL scripts can be served off a plain webserver. All the infrastructure 
is already there. Or how about serving scripts from the browser itself? 
AltME can both be a client and a server. It's that P2P thing again.

- Browser would run wherever R3 runs.


- Market it as Web 4.0. Market it as a direct competition to current 
webbrowsing.


- Browser would be a 500-600 kb downloadable exe that starts immediately 
without installation. From deciding to get it, to be using it to 
browse "Rebpages", it should not take more than 30-45 seconds.

- We need AltME in that browser (Altissimo?) as well as QTask.

For developers:


- It's easy to create an HTML file in notepad and display it in your 
favourite browser. It's going to be equally easy to create a REBOL 
script in notepad and see it running in your REBOL browser. A 5-year-old 
who has just learned to type, should be able to create a script and 
display it.

- One language for everything.


- Everything is free. You can start out with notepad. The barrier 
for creating content is about as low as it can get.


- You wanna code slow web 2.0 apps or fast web 4.0 apps? Hard choice, 
I know.

A REBOL browser is a great way to really get REBOL out there and 
might be used by non-developers just as their browsing tool instead 
of current browsers.

Paul, I began rambling about replacing the viewtop with a browser-like 
deployment platform in the r3-alpha world. I didn't expect that 30 
seconds after posting it, Carl wrote something akin to "Henrik, that's 
basically what I'm doing now." and at that point he hadn't said anything 
for over a week. :-)

This is basically what I meant earlier about being "psyched about 
a REBOL browser". I left out things like video playback and advanced 
audio, because I don't know yet what the approach for making those 
things possible will be. But if they are possible, they would be 
equally possible, like OpenGL would be possible.


And if it turns out that he won't do the browser himself, then it 
can easily be a community effort, not hard to build.

Not hard to build, but hard to design. Graphics models, interaction 
models, security issues, trust issues, resizing and reflow, these 
are all tricky problems. I can see why it would be taking a while 
for Carl to think through the implications.

But a REBOL Browser will introduce REBOL to others that have never 
used REBOL.  And if REBOL gains some acceptance then it means that 
other browsers will have to begin to integrate some compatibiliity 
with REBOL.

Henrik: "When you fire up R3, you will get what looks like a webbrowser 
and acts like one." - not just that, I want R3 not just to look like 
a webbrowser and act like a webbroser but actually TO BE a webbrowser 
- download R3 (few hunderts kB), run it and be able to browse REBOL 
pages - and if you enter *.html - just show some window that says 
"downloading" and download some REBOL plugin that can display webpages 
(being based on Gecko, Webkit, whatever) - it will be few megs download, 
but people are used to it. This is definitely possible - it's possible 
to display OpenGL etc in View window so I believe there are some 
libraries to do this ("somebody" just needs to make an interface 
to them ;)'


The thing is that R3 browser (and just a R3 browser) will be once 
again a great platform without apps (Be Inc etc...). If R3 browser 
can display classic HTML+JS+CSS+DOM+XML+AJAX+WHATEVER combo it's 
win-win situation. Lots of apps available and we can improve them 
one after one to show it can be done much easier and faster.

And simply say "we made a new kind of webbrowser. it's much faster 
than your old webbrowser.". Perhaps market it as a side product of 
REBOL. This would bring up the old discussion again of what REBOL 
is.

Making another web browser won't help - new web browsers are made 
every day,and most don't catch on. Google's Chrome is an exception 
mostly because of the reputation of Google, and some nice features, 
but even with that it is unlikely to make much headway against the 
browsers that people are already using. Web browsers are commodities.

Firefox wasn't an independent branch of Mozilla, it was a branch 
of Mozilla (the software) written and supported by Mozilla (the organization 
with corporate sponsors and backing).

The API isn't set at this point, because of the core changes and 
more.

Well the API wasn't finalized even then, and then would have needed 
to change drastically with the Unicode changes. That doesn't even 
include Carl's current rewrites or the unfinished tasking model.

Henrik - re new name for REBOL browser. You mentioned "side" effect 
or so .... I think that the best so far is FireSide, even if .com 
domain is chosen ... it suggest Fire as in FireFox, FireBird, and 
we aproach it from side. Of course we could come-up with anything 
else ...

If by "like a browser" you mean implement HTML rendering and styling, 
a JavaScript interpreter and all of that, then I agree. If you want 
to implement a REBOL browser, then you are dead wrong. It's not the 
browser part that is the hard part.

I don't see the part to implementing an HTML browser at all - we 
already have those, and they suck.

No, an HTML browser would not allow REBOL to infiltrate the masses 
because they already have HTML browsers and most of them don't want 
to switch. I can see the point to making something that works in 
the browser that they already have, but not one that would require 
them to switch browsers because that would fail.

The latter...exactly.

I'm building an app that works great as a standalone app but I can 
see it working in this "browser" thing as the rebol "browser" I believe 
will be proving a framework to extend my app..things like caht, file 
sharing, and other things not yet thought of. If i I have a base 
of users and I stear them to use the browser as it will provide additional 
benifits to my app..that's a bunch of people nows using it that will 
quickly discover they can also rech the html web. Why us ie or firefox?

For that matter, unless you support their existing web services that 
they already have their data or the data they already want in it, 
it won't matter. That means their existing webmail account and Flash 
video. If you can't play YouTube (and RedTube, ...) it won't matter.


People don't care about the underlying technology unless they are 
techs. If you make a REBOL browser so that you can do REBOL stuff, 
and then try to support the old web stuff thinking that people will 
try the REBOL stuff and find it to be better, you will be wrong. 
Most people won't be able to tell the difference, because it isn't 
the technology that matters, it is the content. If you have the best 
content available in the most convenient way, people will install 
your software to get at it, whatever your software is written in.

The real advantage to the REBOL browser isn't web integration, it 
is taking the real advantages of the web (aside from installed base) 
and applying those to REBOL, but better because we don't have that 
legacy markup crap.

We are not going to compete with Flash directly, not unless we can 
provide a better source of free videos of cats running on treadmills 
than Youtube. The only company that can kill Flash/Silverlight video 
is Google, because they can add HTML 5 video to every open source 
browser and switch Youtube to use it. Nothing that the REBOL community 
can do will work on that scale.

Agree here also, I want cross platform GUI where the rebol browser 
provides UI and other services to applications not just content. 
 The value in the Google applications is not their quality (which 
is okay) but in the access from anywhere feature.  The HTML/Browser 
is trying to grow into the application space but is really at a disadvantage 
because of the technology.

Links, discovery via search, anywhere access these are good things 
that can also be done with the networking strength of REBOL, no need 
to saddle that with HTML/CSS and the whole mess of patchwork technologies 
layered on top.

Rebol is a niche product, and unless it reaches critical mass (of 
developers) will probably remain that way.

Critical mass is a challenge for sure.  I've been bouncing around 
all the "popular" technologies for some time while earning my keep 
with old fashioned database applications.  Some are very interesting 
and have good strengths, none are making creating solutions easier 
or even better in most cases.

Everything is a niche product, even Flash. There is no general purpose 
product. Find your niche and go for it.

For me, critical mass is being able to use REBOL for work and my 
research and not have it be career ending. I'm there already :)

For me the neat thing is that I can give my users access to Rebol 
inside the product and so they can extend the product as they wish.

Obviously this dialect wouldn't be as powerful as the DO dialect, 
but if it is a proper subset it could be executed by DO and its buddies 
as is. Once you have this, all you would need is a syntax transliterator 
and you would have a JavaScript interpreter in REBOL.

It would also bringe the gap of REBOL and....the "web". :)

This is what Gab and I have been talking about, although even more 
abstracted from REBOL <-> JS, more like REBOL->Dialect->anything 
(HTML, XHTML, JS, HTML+JS, etc.)