[roadmap] to be found on rebol.com ...
[1/8] from: carl:cybercraft at: 11-Jul-2004 10:34
A "REBOL Development Summary" has just appeared on RT's site...
http://www.rebol.net/devel04.html
Nice to see - hope they can deliver.
-- Carl Read
[2/8] from: atruter:labyrinth:au at: 11-Jul-2004 11:30
> A "REBOL Development Summary" has just appeared on RT's site...
> http://www.rebol.net/devel04.html
Some tantalizing tidbits of information there ...
Regards,
Ashley
[3/8] from: ed:brittlestar at: 12-Jul-2004 7:47
Carl Read wrote:
> A "REBOL Development Summary" has just appeared on RT's site...
>
> http://www.rebol.net/devel04.html
>
> Nice to see - hope they can deliver.
Per the email subject/title, I do not regard this summary as a roadmap,
which would include dates and/or prioritization.
There are enough ideas listed in the summary to keep a team of RT developers
busy for several years.
Good luck to RT and the community.
Ed
[4/8] from: henrik::webz::dk at: 14-Jul-2004 11:02
Ed O'Connor wrote:
> Carl Read wrote:
>>A "REBOL Development Summary" has just appeared on RT's site...
<<quoted lines omitted: 7>>
> busy for several years.
> Good luck to RT and the community.
Indeed there is a lot to do. I hope RT will allow us to contribute as
much to them as they do to us. Learn from others, form a proper
symbiotic relationship between users, "lieutenants" and core developers,
to help Rebol grow in a clear direction and not mutate into confusion
like many other open source projects without guidance and clear planning.
I will gladly participate in whatever form I can.
--
Regards,
Henrik Mikael Kristensen
[5/8] from: bry:itnisk at: 15-Jul-2004 9:29
> >>A "REBOL Development Summary" has just appeared on RT's site...
> >>
> >>http://www.rebol.net/devel04.html
> >>
> >>Nice to see - hope they can deliver.
> >
It seems to me that "a reb-service is just a remote data access mechanism. It
lets you send, retrieve, and manipulate data remotely by using a very simple
interface methods based on REBOL."
would require REBOL to have some form of capability constraints, tougher than
the current system.
reference would be E: http://www.erights.org/elib/capability/index.html
the Multi-level Sandboxes approach is a good start but is not stringent enough.
[6/8] from: nitsch-lists:netcologne at: 15-Jul-2004 15:28
On Donnerstag, 15. Juli 2004 09:29, [bry--itnisk--com] wrote:
> > >>A "REBOL Development Summary" has just appeared on RT's site...
> > >>
<<quoted lines omitted: 9>>
> the Multi-level Sandboxes approach is a good start but is not stringent
> enough.
Would not need that because the messages are dialect-based. You write a
parse-rule for a mini-langage for your service. Sure you have to add
access-checks in your code, but a message can not execute code.
-Volker
[7/8] from: greggirwin:mindspring at: 15-Jul-2004 10:36
Hi bry,
bic> ...would require REBOL to have some form of capability
bic> constraints, tougher than the current system.
E has some very cool concepts in it (promise-based computing, right?),
but Volker beat me to the punch on why REBOL may not need it so much.
By not exposing the base language, and all its power, we create those
constraints ourselves. What we need are examples and docs on best
practices to avoid security holes. e.g. is CONSTRUCT always safe to
use, is there any way to use DO or LOAD safely when dealing with
untrusted data, how best to use SECURE, stuff like that.
-- Gregg
[8/8] from: greggirwin:mindspring at: 15-Jul-2004 10:40
Hi bry,
bic> reference would be E: http://www.erights.org/elib/capability/index.html
As an addendum, if you or others who have thoughts on this, please do
distill and collect them so we can make sure RT has the information
ASAP. As we hear more about the community organization goals, we can
do our best to get them the info through the best channels.
-- Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted