Idea for rebol.org...
[1/13] from: robert::muench::robertmuench::de at: 18-Mar-2004 9:15
Hi, using rebol.org quite often to get an overview about available code
and collect ideas the following idea striked me.
You know that I see fragmentation of efforts/information as one major
problem, which makes it hard for newbies to get into Rebol. Further
fragmentation slows down "professionalism" of Rebol for business markets.
Anyway, with rebol.org we have a very good reference point. At the moment
it's a portal to get access to scripts, someone owns and updates. Scripts
are independent. The library people introduced the idea of packages, so
now I can add collections of scripts that are related. But still it's only
a one-person show.
How about going to the next level? I would like to see a new section at
rebol.org, that contains a peer-reviewed library/framework following the
concept of the BOOST C++ library. We have a lot of very talented and
guru-level people here, to ensure high quality.
How can such a process look like?
I see the peer-reviewed part of rebol.org made up be several levels.
- Strategy: What do we all need? What's the focus and priority?
- Research: What can we re-use, what ideas, concepts exist, what
succeeded?
- Concept : How should the design/usage/... look like?
- Development
- Review : The Review-Board checks quality etc. on the delivered code and
integrates the code into the overall library.
What gets included depends on the need of the people. The strategy should
give a hint, for what is needed to achieve as much value as possible for
the community. Teams will either form to work on a topic or not. If not,
well, than it's not needed by many.
IMO this will result in a high quality library of code, that fits
together. And that's something we all miss. With the availability of the
browser-plugin, we can even go that far to create a
peer-review-library-application.
What do you think?
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[2/13] from: bry:itnisk at: 18-Mar-2004 13:49
actually I think Rebol.org should have a
wiki underneath it.
[3/13] from: maximo:meteorstudios at: 18-Mar-2004 10:57
YESS TO ALL!
I always wanted such a platform, still do.
so far, it seems to me that rebolers don't play well together (code-wise) unless RT is
giving its approval.
Many people seems scared to work on stuff unless RT is somehow in the loop, yet MOST
of the major breakthroughs in rebol over the last year have been by people who have broken
that mold.
I think rebol.org, with the LDS mechanism has generated a very convenient code sharing
platform, too bad its gone virtually unnoticed.
I'm sure they have such a thing on their agenda... but all in time...
Quite frankly, I'd rather have mailing list searching capabilities on the rebol.org site
in the short term...
Maybe if you volunteer to do some of the work related to setting that up, they'll let
you host it on their ip?
some might also argue that peer-reviewing is what Altme is all about!?
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
[4/13] from: robert:muench:robertmuench at: 19-Mar-2004 16:31
On Thu, 18 Mar 2004 10:57:47 -0500, Maxim Olivier-Adlhoch
<[maximo--meteorstudios--com]> wrote:
> so far, it seems to me that rebolers don't play well together
> (code-wise) unless RT is giving its approval.
Hi, that's right.
> Many people seems scared to work on stuff unless RT is somehow in the
> loop, yet MOST of the major breakthroughs in rebol over the last year
> have been by people who have broken that mold.
Yes, we have quite a lot of gurus around here and lately the cooperation
to focus on one goal seems to become better. The async stuff IMO is a good
example.
> Maybe if you volunteer to do some of the work related to setting that
> up, they'll let you host it on their ip?
I'm not sure if I'm the right one, but if there isn't someone else I'm
available to do it. IMO it's mostly a process topic.
> some might also argue that peer-reviewing is what Altme is all about!?
Maybe but it's closed... we need a way that as much people can use and
participate as possible. Until you know about AltME you are an advanced
Rebol community member. I don't see why we should change best-practice
patterns just to use new technology. We need to address the mass.
People joining efforts for one goal can use AltME to coordinate the
development. You know that I'm working on getting xpeers.net running. I
would like to donate accounts for people developing things for the
peer-group.
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[5/13] from: greggirwin:mindspring at: 19-Mar-2004 12:18
Max, Robert, et al
(pardon any disjointed-ness, this was composed in small pieces and
spare moments)
Sunanda and I are both very busy for the next few weeks, but we'll
keep track of the suggestions made here regarding REBOL.org, so keep
them coming.
MOA> so far, it seems to me that rebolers don't play well together
MOA> (code-wise) unless RT is giving its approval.
My experience is that REBOLers play *very* well together. I've worked
on a number of projects with people from this list and other channels.
What I see as different about REBOL is that all the things we do
remain external from the main distro (as I think it should be right
now). Even if we come up with a great library, it won't ship with
REBOL, so people still have to look for it. This is a big difference
compared to other systems.
To support the reusable/shared code approach in a general way, I think
we need to have some other pieces in place (e.g. how to organize and
define "projects", include other files, etc.). This is where RT comes
into play. There are various INCLUDE mechanisms out there, but RT has
their own (PREBOL); which one to support? We'd all like to see module
support in REBOL (planned and rumored), but if we build our own it
could be made obsolete when their native mechanism becomes available.
So we wait...and build things for ourselves in the meantime.
Package support is a great example. Should it be RIP, ZIP, RPM, doc'd,
with metadata, allow 'includes, etc. We talked about a lot of things,
and would still be talking if Sunanda hadn't taken the initiative to
get *something* out there for comment and use.
A library approach like Boost might help, and I think that's something
REBOL.org can support, though maybe in a less formal manner. I looked
at Boost (and CPAN, Parnassus, etc.) quite a bit when we set up
REBOL.org. We want to improve the guidelines we provide to submitters,
without being overbearing in our formality about it.
>> Anyway, with rebol.org we have a very good reference point.
>> At the moment it's a portal to get access to scripts, someone owns
>> and updates. Scripts are independent. The library people introduced
>> the idea of packages, so now I can add collections of scripts that
>> are related. But still it's only a one-person show.
People can collaborate via REBOl.org. Scripts can be shared by
multiple owners, though I don't know how many people are using that
feature.
I'm all for making things better and I think REBOL.org is the
right place to get folks together to do it. Sunanda has made a
huge difference in the community by taking the initiative and
doing so much work at REBOL.org, giving us something to build on.
We're looking now at making REBOL.org more attractive and useful, so
let us know what you like (or don't), what you want to see in the
future, and what you want to do to help!
Thanks!
-- Gregg
[6/13] from: SunandaDH:aol at: 19-Mar-2004 17:34
Robert:
> Hi, using rebol.org quite often to get an overview about available code
> and collect ideas the following idea striked me.
>
> You know that I see fragmentation of efforts/information as one major
> problem, which makes it hard for newbies to get into Rebol. Further
> fragmentation slows down "professionalism" of Rebol for business markets.
It would take quite a bit of work to make the Library a place for a
collaborative development. I think that sort of project would work best under IOS or
an
Altme world.
But the Library is a great place for publishing the end results.
As Gregg says, it is possible for many Library members to own a single script
or package, so a collaborative development can be published under joint
names. And any of the owners can then update the script or package.
The Library has some tools to make that a little easier -- we archive all
versions of a script, and there is a diff util available to the scripts' owners
-- so you can tell what your fellow owners have done to the project.
You make some good points about raising the quality of future Library
contributions.
Many of those points also apply to existing contributions. There are some
things we can do now to improve the quality of existing scripts
For example, any script can have a discussion thread hanging from it. So, if
you see something that could be improved, or you'd like the owner to add some
documentation, just ask via a discussion post.
But, unfortunately, about half the scripts have no owner. If someone wants to
take on tweaking or improving or fixing those scripts here is an idea....
We have a fairly fine-grained concept of Librarian (aka Moderator)
privileges. If someone (or several people) want to sign up as a Librarian for the
purpose of improving unowned scripts, please let me know. We can give you that level
of access.
Back to your original point about "fragmentation" -- a single, central point
for scripts and information is one way to reduce that. But not everyone would
want that. I've been toying with some other ideas for making the Library a
central starting point for exploring the REBOL universe.
For example, I'd like to add a "Developers Showcase" -- we'd all have a page
each in which we could say what services or tools we offer, with links to our
own websites for more details. I'm hoping to add something like that in April.
What is useful to me (as the current main coding droid at the Library) is
some idea of what other people use the Library for, and what directions they'd
like to see it develop. So threads like this one are invaluable. Please all add
more comments!
Thanks,
Sunanda.
[7/13] from: robert:muench:robertmuench at: 20-Mar-2004 13:10
On Fri, 19 Mar 2004 17:34:46 EST, <[SunandaDH--aol--com]> wrote:
> But the Library is a great place for publishing the end results.
Hi, yes right. That's what I meant. How the result is created shouldn't be
the focus of rebol.org It should be to ensure some kind of quality level.
People know that things available at Rebol.org are cool and that there is
a special section, which has a vision and ensures everything fits together.
> For example, I'd like to add a "Developers Showcase" -- we'd all have a
> page each in which we could say what services or tools we offer, with
> links to our own websites for more details. I'm hoping to add something
> like that in April.
That's a good idea. BTW: I have this idea for xpeers as well. The idea is
to give people a portal, a presentation platform to offer IOS related
services, reblets etc. and to make it easier for people interested to get
a bunch of information in one place.
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[8/13] from: robert:muench:robertmuench at: 20-Mar-2004 13:10
On Fri, 19 Mar 2004 12:18:35 -0700, Gregg Irwin
<[greggirwin--mindspring--com]> wrote:
> My experience is that REBOLers play *very* well together. I've worked
> on a number of projects with people from this list and other channels.
<<quoted lines omitted: 3>>
> REBOL, so people still have to look for it. This is a big difference
> compared to other systems.
Hi, yes that's right and brings it to the point. But we are all a bit too
RT focused...
> To support the reusable/shared code approach in a general way, I think
> we need to have some other pieces in place (e.g. how to organize and
> define "projects", include other files, etc.). This is where RT comes
> into play.
;-)
> There are various INCLUDE mechanisms out there, but RT has
> their own (PREBOL); which one to support?
The one, that's available and works best. If there is an official one, we
can use it and migrate things. Yes, not the best way but at least we get
something done. Oh, and I think if we use a own made one, we can have some
influence on the official version. I'm sure Carl is open to look at our
stuff and happy if he doesn't has to think our all things himself.
> Package support is a great example. Should it be RIP, ZIP, RPM, doc'd,
> with metadata, allow 'includes, etc. We talked about a lot of things,
> and would still be talking if Sunanda hadn't taken the initiative to
> get *something* out there for comment and use.
Correct, he took what was there, and integrated it to get something up and
running. Best shown practice here!
> A library approach like Boost might help, and I think that's something
> REBOL.org can support, though maybe in a less formal manner.
I agree it shouldn't be to formal. I think we should have a vision and
some people taking care, that everything fits together. How a piece of
code is done isn't that interesting... if it's good it will be used, if
not, than not. As said, I see the formal need in the process, so we all
know what we get and what not.
> People can collaborate via REBOl.org. Scripts can be shared by
> multiple owners, though I don't know how many people are using that
> feature.
I expect, very few. Because this is only a tool question in the second
step. The big step is taken to get a team formed. I'm in good contact with
a couple of people here. And works great (IMO) but it takes time to get
people interested and tell them what you want to do.
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[9/13] from: SunandaDH:aol at: 20-Mar-2004 17:35
Robert:
> That's a good idea. BTW: I have this idea for xpeers as well. The idea is
> to give people a portal, a presentation platform to offer IOS related
> services, reblets etc. and to make it easier for people interested to get
> a bunch of information in one place.
You are thinking bigger than I am -- and there is a place for both projects.
I'm thinking more of a sort of YellowPages type overview. A sort of roadmap
so seekers can get a feel for who does what, and where is a good place to look
for more quality information.
A proper directory and resource center -- your idea, if I read it right --
would be an excellent place for co-ordinating all sorts of more in-depth
information and resources,
Let's do both!
Sunanda.
[10/13] from: moliad:aei:ca at: 20-Mar-2004 22:13
IF you had a bad day, don't read this ... this reply is long, it includes
ranting and some clearly biased content...
:-)
I also want to say first-off that I respect EVERY member of this list.
especially those of you who've spent hours on end doing tools that many of us
use day in and day out.
> > To support the reusable/shared code approach in a general way, I think
> > we need to have some other pieces in place (e.g. how to organize and
<<quoted lines omitted: 3>>
> > There are various INCLUDE mechanisms out there, but RT has
> > their own (PREBOL); which one to support?
slim !? ;-)
the name says it all, it keeps your apps slim.
hey, self promotion is healthy for the spirit ;-)
maybe I should work on the linker, so that packaging all of that code is
easier... it was supposed to be part of forge... I don't know... no one ever
told me.
> The one, that's available and works best. If there is an official one, we
> can use it and migrate things. Yes, not the best way but at least we get
> something done. Oh, and I think if we use a own made one, we can have some
> influence on the official version. I'm sure Carl is open to look at our
> stuff and happy if he doesn't has to think our all things himself.
Yet even when people do create API-like tools... the user base is so small that
there is not much feedback, except for the very widespread usefull stuff like
the async stuff. A lot of people are talking yet I do not sense a great need
for run time linkable code.
When I released slim, many people where saying that a dynamic loader was in
dire need. WELL I delivered something... something which is meant to releive
the programmers from stress of namespaces and which even allows you to rename
what is exposed. it supports nested libs, it prevents load cycles , even if
they are present, it even allows you to include a custom validation routine, to
make sure your code is in proper context.
It even includes an encompassed I/O system for a file sandbox of any package
files you need to load.
and on top of it I took 20 hours to document it...
Yet only one person gave me real usage feedback.
I'm not saying that I have the perfect tool, far from it... yet if no one tells
me how to make into what they want, or everyone says we need something and yet
they do not really try out what HAS been done... then I do feel there is a
little bit of irony in all this discussion.
As rebolers, I think we all want to use tools which we built ourselves... it
seems to be part of what coding rebol is meant to be... yet I think there are
many more people who would rebol if that where less true.
Many say, what's the point RT, will eventually " xxxx " ( fill in the hole )
.... IF we all wait until the miracle solution appears, then we will wait
forever. and be warned, RT does not always give that miracle solution. many
things within the standard release are flawed... I'm not saying rebol is
flawed, only that Carl, can't do everything right all the time (now I'm sure to
be torched... ;-). Things evolve and many of you have provided better
solutions to given problems. async ports, xml tools, ftp patch, mysql, etc.
even the vid 1.3 is based on many user submissions which have been around for
AGES.
I have provided an attempt at filling a HUGE gap in rebol's arsenal, one that
comes back all the time in discussion. can someone at least try it... or tell me
what is wrong with it... tell me how to make it better, to explain this or
that... to even send fixed or better code for any given thing? yet so far,
only two persons have really done anything with it. one has sent me a list of
typos in the doc (which incidentally means he actually read it... thanks,
again) , and the other told me "thank you, that it was time for someone to try
to build and release a framemork of complimentary tools".
do I seem a little frustrated ? ... YES... I'm frustrated that people talk.
people wait. Yet many of you are working on excellent api-like tools. I'm not
saying that the Rebol community is a bunch of this or that. only that many
times, and on many distinct issues, it seems people here are scared of claiming
that maybe they ARE as good as RT in any given tool. For some reason, many of
you are scared of claiming that you are able and it seems that there are many
excelent modules, just ready to be united into a package, which given proper
support and user trial, would relieve RT of many issues...
I mean, do you think that I can do anything about porting view to MAC OSX....
nope. I'd rather have RT work on that. and adding C source code to effect's
pipe, fixing(documenting) the image datatype (which has been done, btw). adding
new binary functions which allow us to use external dll data directly, without
any slow conversion, etc... porting the new plugin to linux, mozilla, fill-in
your needs here, etc.
> > Package support is a great example. Should it be RIP, ZIP, RPM, doc'd,
> > with metadata, allow 'includes, etc. We talked about a lot of things,
> > and would still be talking if Sunanda hadn't taken the initiative to
> > get *something* out there for comment and use.
yess and it is an AWESOME engine... its documented and soooo easy to use. plus
If I'm not mistaken it uses an http transport, which means that you can use it
through a firewall and proxy which blocks most other ports...
> I agree it shouldn't be to formal. I think we should have a vision and
> some people taking care, that everything fits together. How a piece of
> code is done isn't that interesting...
yet it should also allow for diverging tools to be included together. as long
as they are usable in the same manner. The fact that two people have different
views on how a problem can be solved, should not prevent one from getting into
an "official" distro. Users will decide. and there might be tools which are
complimentary anyways. two peoples math libraries could provide the same
functions, yet have differing preoccupation. one might be precise, the other
might be fast. Equal yet not.
What I mean is that peer-review is good, yet because of rebol's do it yourself
nature, it should not be exclusive, it has to be inclusive. the group of peers
must not be the singular. It should be able to have more than one commity so
that different groups of coders can collaborate on different packages which
Might just include all the same kind of tools.
> if it's good it will be used, if not, than not.
not always true... other wise rebol's user base would quintuple in a month....
;-)
people need to be aware, they need to learn, and they need to be convinced that
switching to a new tool, is less hassle than continuing with a "lesser" but
understood tool.
I hated using python in the begining, but eventually, I found out that even it
has things which I miss in rebol. so both are good tools, yet have very
different goals.
> > People can collaborate via REBOl.org. Scripts can be shared by
> > multiple owners, though I don't know how many people are using that
> > feature.
it needs promotion... something which should be made more obvious in a newer
site ';-) as are MANY other features.
> The big step is taken to get a team formed. I'm in good contact with
> a couple of people here.
The dream team ;-)
> And works great (IMO) but it takes time to get people interested and tell
them what you want to do.
Yep!
Yet I find that the system should work like sourceforge where anyone can start a
new "peer review group" There should not be only one all encompassing team.
This means the same kind of tools can co-exist, yet have different mindsets.
none of them are inferior. I can say that I -like- a tool better than
another... nails or screws... some people prefer nails, yet some prefer screws.
both are fasteners, and both have advantages and disadvantages. If someone in
charge of a singular working group said that their box does not support screws
then what interest is there in that box for those who prefer nails? not much.
I'll finish with this:
REBOL is an excelent tool. It has an amazing community, it has Amazing
developpers, and its now starting to mature into a platform with amazing
tools...
-Max
[11/13] from: robert:muench:robertmuench at: 21-Mar-2004 13:35
On Sat, 20 Mar 2004 22:13:55 -0500, Maxim Olivier-Adlhoch <[moliad--aei--ca]>
wrote:
> IF you had a bad day, don't read this ... this reply is long, it includes
> ranting and some clearly biased content...
Hi, well yesterday was my birthday, so I think I can take it :-))
> slim !? ;-) the name says it all, it keeps your apps slim.
> hey, self promotion is healthy for the spirit ;-)
Ok, I'm going to give it a try and see how it works. If it's good we see
if we can integrated it into xpeers.
> I'm not saying that I have the perfect tool, far from it... yet if no
> one tells me how to make into what they want, or everyone says we need
> something and yet they do not really try out what HAS been done... then
> I do feel there is a little bit of irony in all this discussion.
That's right. It's the cirtical mass problem. Either the need isn't really
that high or the tool doesn't has an USP. The former is most likely,
because it's very easy to request something and tell it's needed. I always
ask people to provide a concrete use-case to show for what they need
something before I start working. In 80%+ of all cases, the request is
solved in 5 minutes, because the requestor understands, that the request
wasn't well thought. I don't expect this to be a problem of a bad tool,
because in this case, you definetly had got some feedback.
> Many say, what's the point RT, will eventually " xxxx " ( fill in the
> hole ) IF we all wait until the miracle solution appears, then we will
> wait forever. and be warned, RT does not always give that miracle
> solution.
That's why I started this thread. IMO we need to do more ourselfs in a
more structured way to gain much more value from the work people like you
have invested. There is a bunch of stuff outthere, cool stuff, but it's
not used. Why? That's the question to solve...
> or tell me what is wrong with it... tell me how to make it better, to
> explain this or that... to even send fixed or better code for any given
> thing? yet so far, only two persons have really done anything with it.
You asked for it... you will get it.
> yet it should also allow for diverging tools to be included together.
> as long as they are usable in the same manner.
Yes! You know what I hate most abount Linux? I have a mass of tools but I
need to throw it together on my own. I need to twiddle around with
hundreds of files etc. I want a set of tools and code, where using this is
a no-brainer. Than it will be used. Simplicity! Getting rid of non-value
complexity.
> What I mean is that peer-review is good, yet because of rebol's do it
> yourself nature, it should not be exclusive, it has to be inclusive.
> the group of peers must not be the singular. It should be able to have
> more than one commity so that different groups of coders can collaborate
> on different packages which Might just include all the same kind of
> tools.
My vision is to have a pyramid of review steps. Each level reviewing a
specific part. Basic tests, integration tests, vision compatibility etc. I
just want to be somehow sure, that if I download a peer-reviewed piece
from the library, I can reuse my knowledge about how to integrate things,
how this stuff works etc. I don't want to start over and over with each
piece of code.
> people need to be aware, they need to learn, and they need to be
> convinced that switching to a new tool, is less hassle than continuing
> with a "lesser" but understood tool.
Good point, and I add: They have to see the investment is worth for the
future...
> Yet I find that the system should work like sourceforge where anyone can
> start a new "peer review group" There should not be only one all
> encompassing team.
I would like to put more effort upfront to form a bigger group. You just
said, the problem is that only two people gave feedback. If you have 20
options to choose from and there are 40 people, the chances are low that
they will pick your solution. It's the fragmentation problem...
> This means the same kind of tools can co-exist, yet have different
> mindsets.
That's what we have now...
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[12/13] from: robert:muench:robertmuench at: 25-Mar-2004 8:10
Hi, I want to give a follow-up input to our peer review discussion. IMO
this topic is still an important one, because it can make it easier for
new people to get started quickly with Rebol. Further it should help us
all to implement our ideas much faster if we have a good library.
There is so much good code out there, that it's a pity if it's not used
just because there is no place to look for, no support from an active
community, you name it.
I decided to give this idea a test after Max jumped in and gave an example
WRT his efforts. He mentioned his slim library manager and that the
feedback was mostly none. I'm currently assembling a framework for IOS
development and thought, well, let's try it out and see what's behind this
stuff.
I took me around half a day to read thru the docs, create some tests and
finally make most of the code I wanted to put into the framework
compatible to the slim library manager. To be honest, I didn't expected
this! Well done Max! This makes my life a lot easier now.
I don't want to start a discussion about slim here, but it's a good
example. We have a nice tool, we have a library but what's missing is the
integration step. If slim doesn't fit our needs, or can be optimized or
whatever, I'm sure Max is open for suggestions. Even more, I think people
interested in how to handle library and modules, should jump in and
peer-review what we have with slim. It might not be the best solution, but
it's a very good start that works out easy.
I would like to test, a peer-reviewing of slim. It's a good test
candidate. And I'm sure within a very short time, we have 90%+ of the
library manager we all want, that everyone can use, and that is optimized
thru the Rebol gurus here.
Who is interested?
--
Robert M. M=FCnch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
[13/13] from: maximo:meteorstudios at: 25-Mar-2004 8:46
hi all,
just wanted to but in and say that I will be releasing v0.9.4 of slim later this evenigng.
it fixes a few bugs and internal I/O should now properly propagate errors back to main
code, instead of failing inside encompased function... this lets you use
error? try [read %file]
on reads as usual and react if there where errors.
It will be on rebol.org and will be distributed under lgpl "with no strings attached".
HTH!
-MAx
---
You can either be part of the problem or part of the solution, but in the end, being
part of the problem is much more fun.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted