Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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