AltME groups: search

To become part of the RP a library will need to adhere to these requirements:
- BSD license
- docs in HTML/makedoc
- code accepted by RP lead

The powerpack has Carl's blessing. The idea is to provide a quality 
assured set of libraries that can help (semi-)professional developers 
to get things done.

Have a chat, if you haven't already, to Robert about the RPC as there 
may be some overlap in efforts. I'm more than happy to work with 
you to ensure RebGUI fits the proposed model (from both a code and 
documentation perspective). Some things to consider:

	- Coding standard(s)
	- Documentation standard(s)
	- Optimization methodology
	- Testing methodology
	- REBOL baseline (I'd aim for 1.3 - forget the past)


I've said this to a few people on AltME already, but for this type 
of project to succeed it needs four things:


 1) Technology (including a sound & easily understood conceptual basis)
	2) Documentation (good documentation is better than good code)
	3) Momentum (a sense that things are happening)

 4) Community (an environment where people are encouraged to contribute)


Getting all four right is *hard* work. *My* definition of success 
for a project is to be able to answer YES to the following two questions:

	1) Does it work?
	2) Is it used?

Ashley I'm Absolutly agreed with your point of view  !!! The way 
to participate actively to a project can take a lot of shapes. 1) 
make doc 2) making code optimisation 3) adding brand new code 4) 
debugging 5) giving feedbacks and needs 6)  making translation 7) 
making sample code (as far as I saw in my peronnal experience it's 
easier to understand how to use a thing if you provide a sample code 
that's an illustration not a goal. Sample code alone are only accessible 
to yet powerred users. Documentation without sample code is abstract. 
That's for example what I like in the rebol documentation diccionnary 
it explains and shows you concretly little sample to pretty understand 
the cancept explain... Making good doc is a hard and painfull task 
... If it belongs only to one people my personnal expirence shows 
me that the effort is not made along a long time... so it's obvious 
that we need a doc commity where people emulates each others and 
fixe periodically new goals. In French speaking community we all 
share teh same point of view that' why we try to put at disposal 
of all the people some usefull tools like a dokuwiki in http://www.rebolfrance.org
and doc collectors in http://www.rebolfrance.frand http://rebdocproj.sourceforge.net/) 
our public is french speaking mainly but we are so few that we can't 
say hey our tools are for french speaking people only. So if those 
tools seems you usefull for any project and any information sharing 
or cooperative work go ahead use them ;)

a good documentation must respond to all type of question and knowledge 
... Using cooperativ dynamic writing/publishing  tools other to redactors 
and readers a close interaction if you read a documentation and steel 
have questions you can mail, altme, or forum the redactors to makes 
your ask in order for them to bettering the documentation  very fast

for example on french scene forum the amount of information on rebol 
coding is so high that we can't easyly synthetise it into a meanning 
documentation. Why ? because structural we choose a forum based interface 
betwin coders without taking strictly the time to produce a syntetic 
documentation for every issues that were submitted and discussed 
on the solution apported from the very beginning (a participant number 
issue is in the scope  too )

So know synthetising the informations on our forum to make it disponnible 
for every one is a very very hudge task (more than 20 000 topics 
it's hard to sort and put in value ...)

the inter documentation referecing is too a weak point some needed 
concept are maybe availlable yet some where but then you need to 
specify it into your documentation to orient the reader :)

Note that RP will be bundling all those good (proven?) libs and make 
them accessible from one place. Your rebgui, but also mysql:// are 
excellent examples. But imagine your new to REBOL, wouldn't it be 
nice if there were a link on rebol.net /.com that gave you immediate 
access to these libs?

That's why I am doing this. I will start as Strong Leader, simply 
to make a Fast Start. Once the powerpack is well-established others 
may (and probably want to) join.

Can Uniserve be used for a "rails" implementation?

I'm building some extensions for pdfmaker so that might be a good 
one

Uniserve is very nice, I have been using it to prototype/test before 
I upload to actual server.  It broke my heart it was gpl.  BSD is 
very good choice.  Free software should not be restricted, and GPL 
has too many of those.    makedoc/spec is the killer app,  and in 
that intensional programming vein is coursing all the best documentation, 
and REBOL  does a fine job of documenting itself because it is so 
semantic by nature.  To understand how to use a moderately complex 
system like a full-featured web server, it is going to be important 
to capture the thinking of those who wrote the code.  REBOL parsing 
allows all information pertaining to the code to be right there with 
the code,  and a function of  DO -ing anything.  the standard documentation 
scheme should follow how REBOL [] headers work, and simply have the 
makedoc embedded within the scripts.

what do you mean by jailable.  not a term I am familiar with regarding 
software.

no, I am saying that any software that purports to be "free" should 
not restrict my use.  It is not free if it forces me into a box.

Like we have a Doc Friday now, we'll have an Answers Wednesday from 
now on. I will post answers here each wednesday.

Q. Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?

(Hmm, I'll check back in a week for the answer)

(Copied from rebcode group) Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.

(By request, relayed from rebcode group) Could you add an APPLY opcode 
to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).

Requiring the argument block to be a literal makes the opcode more 
JITable :)

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

Thanks Gabriele and Carl.

How about web publishing the answers somewhere, so the millions without 
Altme can see them?
Perhaps as a weekly blog?

Web-public already ---- True, but only for a month or three, depending 
on the Q&A rate.
http://www.rebol.net/altweb/rebol3/chat390.html

shows only the most recent 300 messages.....Many web-public groups 
have "lost" a lot of valuable discussions that way. A more permanent 
and Google-friendly home is needed for much of this.

A: I'm not sure what is meant by the path for it. You mean for refinements?

Yes, that is what I meant. If it is a major slowdown to check for 
this, add the APPLYP opcode I mentioned for the more general case, 
or have APPLY for the general case and APPLYF to apply functions 
only. Or you could just apply functions and have the refinements 
case be put in a do block or a wrapper function. You can handle refinements 
in rebcode, right?

There are a lot of functions in REBOL that return the value none 
to indicate failure. Could you add an opcode
    none?: ["Set flag if value is none" word!]
to test for that?

btw, i think we should have a separate channel for enhancement requests...

Did I miss a Wednesday ?

Gabriele -- could you point Carl to Feedback message #5a5e09270?
It's been unanswered for a couple of weeks.

Basically, asks if there is any plans for formating numbers -- as 
per the discussion here (core group, 5-oct)
Thanks!

Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.

hello, where I could  find facts and values about Rebol vs Business 
world ? with reboltof (christophe Coussement, we have the project 
to write a white paper about Rebol and Business (target date, on 
March 17, 2005, for the french Rebol Day, Paris). How many developpers 
works with Rebol ? how many dowloads of Rebol/core and View ? How 
many licenses for SDK ? Examples of Business with Rebol, tools, softwares. 
Real-world softwares.... etc.

there's a place set aside for that .. go ahead.

as far as i remember, i wasnt able to try it out because the description 
was not obvious for a newcomer. maybe now i would succeed trying 
it

I'm not sure, how to make a use of it, but it does have an effect:
>> blk: [a b c]
== [a b c]
>> path blk 3
>> blk
== [a b]

>> x: [a b c d]   path x 'c   x
== [a b c]

looks like a kind of inconsistency

Not strange. it does a path-lookup. 
!> a: [b 1 c 2 d 3]
== [b 1 c 2 d 3]
!> a/c: 22
== 22
!> a
== [b 1 c 22 d 3]
!> a/4: 222
== 222
!> a
== [b 1 c 222 d 3]

Here's a question for RT:

Should I wait on my feedback on the new rebcode docs until the next 
version of the interpreter, after the great rename?

I'll do a critique this evening, then.

I've got a question for RT about rebcode. Is rebcode going to support 
paths and/or some kind of binding? Thanks

Kru, one of the list of suggestions we compiled for rebcode was a 
BIND opcode.

What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?

Please, could RT post a small update in a form of short blog article 
about current state of developments? 14.11. was missed without single 
note ...

thanks a lot ...

Gabriele, your introductory posts in this group said: "I will post 
answers here each wednesday."

There are some questions that are several wednesdays overdue for 
a response.
Are there issues with continuing this group?

Interesting!. Do you have a link?...

No. IIRC Gregg was involved? I guess a google with "rebol" could 
help

Some questions for tommorows Q&A wednesday: 1. What is fixed/added 
in 2.6.2/1.3.2 (change-log, please) ? 2. What is planned for 1.4.0 
(rebcode, rebservices, rich-text, RIF, and last but not least, fixed 
sound ...) ? 3. When can we expect 1.4.0 ? Thanks.

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

A: "I estimate that rebcode would be about two times slower than 
it is now."

Q: "One Laptop Per Child"

A: "My current understanding is that the target software is Smalltalk 
based"

Why not integrate rebol into smalltalk? You proposed a rebservice-access-library 
anyway, which - ups - is accidentally a real rebol under the hood. 
I expect that smalltalk is squeak, as i saw Alan Kay within the supporters, 
and Child and latops is his long-running topic. If, its multi-platform 
too, maybe we could even use squeaks multimedia in our lacking areas.

In response to the answer to my question about the path action (thanks!) 
I wonder, why do internal functions like path and native need to 
be assigned to global words at all? Can't they be assigned to some 
internal object fields, or in some way be hidden? I know that encapsulation 
isn't really REBOL's style, but littering the public interface with 
undocumented natives that can't even be used by mezzanine code seems 
a little silly.

As for the question about rebcode binding, let me make it clearer:


It would solve all of the object field retrieval problems in rebcode 
to have an opcode added that would be the equivalent to the IN native, 
or maybe BIND. You wouldn't need path evaluation to be added - you 
could just retrieve an object field word and use setw/getw with it. 
Yes, you can use apply, but it is very slow in comparison with opcodes. 
Working with object fields is a pretty basic operation that doesn't 
have any direct support in rebcode, and some have come to miss it, 
particularly those that use objects in data structures. I often use 
blocks for data structures when I can because of the context overhead 
of objects, but some are more used to thinking in object-oriented 
terms. Plus, there's all of those built-in object-based structures. 
Still, I suspect that many of these questions would go away if apply 
was faster :(

Yes, this bind-like opcode was one of the requests that we came up 
with when we were compiling a list of rebcode enhancements. Thank 
you for implementing many of the other enhancements on that list 
:)

Do I need to compile a RAMBO request?

(Still to Volker for this) By using in rather than bind, you save 
a set instruction. Of course if the "object" word refers to a word 
rather than an object, that advantage is less so because we will 
have to convert the word to its context like this:
    apply w bind? [object]
    apply w in [object w]
    getw value w

But for that to work we would need a new rebcode alpha with the 2.6.2 
enhancements.

note that if speed is what you are after, this is likely to be the 
fastest way; if the object changes in a loop, then the rebcode advantage 
is probably not big, though i understand there may be cases in which 
a BIND or IN opcode would be desirable...

Well, it would help for using rebcode as a compiler target (pet project)... 
Still, there have been a few requests for this kind of opcode around 
here, particularly from those using object-based data structures. 
The overhead of such code would go way down if there was some kind 
of fast field access.

Allright, here's a Q: Can we get a new rebcode alpha based on the 
2.6.2 enhancements?

Q: What will be the future plan with the browser plugin, say within 
the next 3-6 months? How much more do we need before it can be called 
production ready? I have a few large scale projects that require 
a production ready plugin (so users won't have to download and install 
an executable).

(just to give you a quick - but unofficial, so don't quote me on 
this - answer, i think that the development for the plugin will be 
done completely outside of RT, for example as a community project. 
so it's very unlikely that RT will be able to give you a schedule 
on this.)

pity we don't know RT's priority list even a bit. 1.3.2, that is 
the cool thing. However, async kernel retired no-one is able to know 
for how long, rebcode is retired no-one knows what and when happens 
to it (e.g. will there be bitmap opcodes as discussed implemented?), 
unicode, rif (where even RT admits it is important for Altme2.0/coop 
project, rebdb is stagnatting because of that), rebin, we wait for 
what-is-going-to-happen-with-VID since devcon, being said we will 
know "soon" ... etc ... So, what is next, guys, and when? :-)

It is not about "we tell you and you quote us on that" thing, but 
about bit of a planning for others ... we surely don't want 14.11. 
exact dates :-) Just months, average ....:-)

I agree. 14.11 is a bit far away. Month would be a lot better! (Did 
i miss something? Opps, SCNR ;)

Volker, that 14.11 was a joke reference to 14-Nov-2005, the date 
given at the conference to all questions about release dates, not 
a version number. That date was given as a joke that many didn't 
get, apparently. Myself included, but I didn't make it to the conference.

Briah - Volker surely knows it was a joke ;-) He just tried to point 
out imo, that we could get some features schedule in months or year-quarters 
...

Hey, noone told me it was originally a joke until after services 
showed up early. Just trying to help :)

It's funny, I had to reboot Windows more often while testing rebcode 
than I have ever needed to for an entire year with that computer. 
Server 2003 is very stable, but crashing processes a dozen times 
or more a day can wear on it a little, so I needed to reboot every 
couple days. Normally I would need to reboot only for occasional 
updates of certain third-party software, never more than once a couple 
months.

OTOH, rebcode is great if you know what you are doing, or are running 
code written by someone who does, or generated by a code generator 
written by someone who does. The semantics seem to have stabilized, 
so you can get to work on those generators. When they resolve the 
crashes rebcode will be pretty sweet for REBOL.

nobody knows - scroll up a bit - I asked the same question not so 
long ago ....

Thanks, Peter and Pekr. But of course I am a little disappointed 
as I badly need unicode support right now.

I wonder if there is a C dll somewhere that would give unicode support 
to the SDK. I have been searching the web for one, but haven't found 
anything yet. I hate the thought of going back to C, as I haven't 
programmed in C for a long time.

Louis - php uses its "own function", called iconv. AFAIK, iconv is 
unix utility, maybe you can use that command-line tool or maybe it 
is available as a library? Dunno ...

Displaying is probably the most difficult, specially for indonesia 
language. Conversion should be that hard. I guess you are receiving 
your data in unicode format. So you will need a parser to scan the 
bytes in the unicode buffer (a simple string!) and maybe generate 
the display by using the glyphs that encode each char.

Now I don't know anything about unicode format, but writing a parser 
for it, should be that hard.

YekSoon: Presuming the "Indonesian Language" is Bahasa Indonesia 
and not one of the hundreds of native languages, the difficulty will 
be if it is written in Jawi script. (Which I'm sure you know is Arabic 
script with a couple of added letters).

petr: actually even a static image with a "password" to copy stops 
99% of automated spam scripts. anyway the situation with rambo is 
not that bad yet. i just wish i could delete that spam myself.

I was away for a week plus few days, and I thought that maybe I will 
be suprised by some new releases of Rebol. With RT announcing removal 
of alpha releases it seems to me, that they also managed to remove 
steam out of the community once again ... ? At least ppl had something 
new to test, post new request, ideas, etc. Now we once again don't 
know, when things like Rebcode will return back, or how Rebcode will 
be further developed, as we know, it misses security things ....

question: I own a Linksys WAP54G access point which runs on a MIPS 
processor with a small Linux server on it. I tried loading REBOL/Core 
for MIPS onto it, but it couldn't run.


The thing is, there is quite a lot of embedded hardware that runs 
such small linux servers. It would be easy to make control software 
via REBOL, connected to a PC running an encapped REBOL/View application. 
This would allow for rich realtime control software, rather than 
using the normal (slow and non-realtime) built-in webserver. I already 
managed to get realtime readouts on signal strength, by polling the 
access point through telnet and displaying a simple meter in a REBOL/View 
script, something not normally possible. But  you could do much, 
much more, if you could run /Core on it directly. I think there is 
a lot of unused potential here.


Would RT consider such ports of REBOL/Core to various embedded hardware 
products and provide a list of embedded hardware products that can 
run /Core?

Will REBOL/View support MacOS for Intel? I plan to get a MacBook 
Pro (Intel) Notebook. I would love to work on my REBOL projects in 
MacBook Pro.

What's the current state and future plans of Rebol/Services? It's 
been a long time since there have been any news ...

just to keep you informed (this is not an official announcement, 
we will be releasing a roadmap soon), the development of REBOL 3.0 
is starting. no eta or feature list available yet.

RT may want to try and replicate this install/uninstall inorder to 
confirm whether there is a problem with the installer.

It's not going over very well with my five web-developer colleagues... 
they are saying he has been infected by the Rebolla virus and getting 
a very good chuckle out of it!!!

no, it only seemed to delete registry settings and the appdata/view 
folder.  Nothing from his program files folder was erased, which 
is a good thing for him.

we must not view rebol in the browser as a means to distribute any 
apps.   I also think the plugin should have a complete control panel 
which allows user to choose from "allways/ask/never" for every sensitive 
aspect.

Rebol as a plugin is here more then 2 years. It was plenty of time 
to do evil things

Pekr, you can not build smtp if the sandbox does not let you connect 
to a mailserver.

And a good sandbox lets you connect only to your homeserver, where 
the reblet comes from.

And I'm sure, you will not be able send emails from my browser as 
I don't remember that I allowed to use such a port to any application

You can also run a mail-server on the machine where you host the 
reblet, then send works.

Without that restriction rebol is a perfect tunnel through firewalls. 
Connect to home, connect to localhost/something inside lan too, have 
fun.

OTOH users want to send emails. But with their own trusted app, not 
with a high-performance hidden 'send. So 'send should pop up that 
mailer IMHO.

with browser - you can connect to whatever port too, no? It allows 
for url schema, so localhost:1234 is valid too .... just a http scheme, 
but ...

The urls are blocked so you can not reach a "legit" mail-server so 
you can not 'send.

But let the networking in, it's the best thing in Rebol. I'm using 
plugin only as a IRC. I really don't know if it can be compared with 
Flash so someone would make stupid banners in Rebol

but system dialogs are half-way solutions - 1) they can't be translated 
2) they are ugly and do not copy design principles of your apps .... 
stating that - is there a secure way of how to overcome this? Could 
you provide your own UI and supply it for the internal security system? 
Probably not, as I could ask user completly different question :-(

1) They can be translated.
2) They are a necessary evil.

I like that ugly and different. Tells me i am not working inside 
the app. Because inside the app, if it asks me "Do you like [x] please?" 
i click yes, whatever [x] is. Its in a sandbox, no?

If I can't control the plugin, Petr, I am not going to install it. 
I'm not going to develop for it, because there will be no reason 
why anyone will trust it. Well, you will be able to do that. Perhaps 
in a separate version of the plugin which might come later.