Slashdot Mirror
Open-Source Component Repository?
The following was submitted by Aiken:
Premises
- Companies that do extensive programming develop their own software libraries... binary trees, networking code, graphics routines, things that need to be done in all sorts of programs.
- While the open-source community has developed excellent tools (emacs, ecgs, etc.) to do their programming on, we have not developed such components.
- A critical issue facing open-source developers is how to find other developers who will contribute to their project.
- Having access to well-tested and proven components such as these could greatly decrease development and testing time needed for other software.
Conclusion
The development of a central GPL'd component repository would be an asset to the open-source community.
Elaboration
Consider the Standard Template Library. Linked lists, stacks, queues, and the like can all be used without having to write them from scratch and debug them. This saves time and improves readability, since they follow a common syntax and have common operators.
The open-source community is not bound by restrictions held on the standard library. We can write code that deals with networking and image formats that are commonly used, regardless of whether or not they are in the standard.
Generating repositories of these components would allow casual programmers to dip into a vast resource base. Instead of spending their limited time finding other programmers to help out, they could simply take and use the code that was already written for them. Rather than create a subroutine for a single program, you would create a component which could be used in hundreds of programs by developers you didn't know existed.
Issues to Consider
Just some kinks in the idea that I can see needing to be worked out:
- How to ensure that components are GPL'd... e.g. that some student's university doesn't want to claim credit for the code they wrote
- How to ensure quality code and documentation
- Who should run the repositories
- What components to provide
Thoughts? aiken@quakemail.com.
The various libraries gnome uses?
The CPAN PERL modules.
MiscKit. gnustep.
To name a few off the top of my head.
It's like the Giant Java Tree... I don't see any reason why it would be a bad idea. The worst that could happen is that a few projects get a new home.
æeee!
Freshmeat is a references repository where you find the links to each project's home page and download places, but (as Murphy said) when you find in Freshmeat the app you need the most, the ftp server where the app is suposed to reside is offline and the project's home page is offline also. You then just end with a bunch of useless references.
The need is for a central FTP repository (with enough mirrors) where every project leader should upload every project's release.
Then Freshmeat should have the reference to the project's home and to the directory in the repository where you can get the sources.
--
Perl has just such a thing (as I'm sure most of you know) - CPAN, the Comprehensive Perl Archive Network. I've done Perl development from time to time and I've often found very useful things in CPAN which I could directly apply to my work.
I program primarily in C and have never seen the C CPAN equivalent... I would love to see a widely mirrored repository of reusable C code.
As far as quality goes, CPAN seems to be of very good quality... I have no idea how submissions are handled, but I assume there's some sort of acceptance process. If it's all self-regulated I'm impressed.
/* The beatings will continue until morale improves. */
It seems to me that this *has* been done before, with much success. I'm referring to the Comprehensive Perl Archive Network.
CPAN enables the Perl programmer to not re-invent the wheel one more time. I'm sure that most of the people here are aware of it (being that there seem to be a lot of Perl bigots here).
I think that something similar could be set up for C/C++ code, but I'm not volunteering! =)
I don't really know if freshmeat is the right location for something like it, but that's purely subjective.
-----------
"You can't shake the Devil's hand and say you're only kidding."
If it's going to be GPL'd only components, then the majority of Open Source licenses will not be able to use any of them. So why call it Open Source? Why not simply "The GPL Component Repository" instead?
Far be it for me to tell the repository maintainers which components they can or cannot accept, but I think if they were a bit more flexible, and allowed at least LGPL components, then it would be much more useful for the Open Source community. I think the freshmeat method of listing which license a component is under would be even better. Then we could have GPL'd, LGPL'd, BSD'd, AL'd, MPL'd, etc, components, and a developer could choose which component best met their needs.
A Government Is a Body of People, Usually Notably Ungoverned
The General Public Virus is all very well for something like Linux, where the only thing you are likely to derive from the existing codebase is -- another Linux. Components are meant to be generic and widely-usable by their very nature. Will putting them under GPL mean that they infect the code that utilises them? That is the GPL's intent. This will make such components unusable not only in proprietary software, but also in BSD-licensed software (and public domain software for that matter). Such a severe limitation is counterproductive, in my estimation, and will probably limit the potential success (measured in terms of active users and contributors) such a project might otherwise enjoy.
I would therefore suggest that the LGPL be used in preference to the GPL, if one insists on a GNU-derived license.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
The next big thing is documentation. Some sort of XML standard for code and project and app documentation (separate, of course, but related), would be just dandy for everything. Relating everything ala one standard is what makes things work in nifty ways.
And a centralized source would be great. ie. something to Linux what CPAN is to Perl. That'd be a *huge* repository, difficult to update, on ultra-fast servers. That makes things very difficult to find as well. (See microsoft.com)
These things are difficult to implement without a given infrastructure. Without said infrastructure available to everyone, and used ubiquitously, things will probably centralize around companies such as Caldera, Red Hat, Corel, et al. The only difference is that, instead of a centralized repetoire of Linux software, it's distributed (perhaps with lots of overlap) between companies. That might be a good thing, though, as there is no central point of failure, and it is a competitive system.
My wish list. :)
This is not a bad idea, but there are some issues you are going to have to deal with.
First, for this to be of maximum effectiveness, you need to make some evaluation of the quality of contributed code. One of my big problems with Freshmeat is that, when I am presented with 17 http proxy servers, I have no idea whch one is the freeware standard under active development and which one is some guys perl script until I download them.
Second, in an ideal world there would be some standards applied to the modules. What do you do when you have three different tcp/ip socket abstractions, dependent on three different string classes? And you also want to use the database class, which is dependent on a fourth string class?
Also, don't confuse components with just code modules. Components are bigger, and have a simpler interface. Typically, they represent a significant body of code, unlike a function. Component based programming is about plugging together the components with very little glue code: hardly the same thing as a "function library".
Also, it seems to me that for maximum effectiveness in components, you need a standard in interfacing them above and beyond a functionc all interface. Currently, GNOME uses CORBA, KDE is using something of their own spinning based on libICE and their own RPC mechanism and CORBA (ARG!), and everyone else is spinning and just using libraries.
So, you have three choices. Pick between GNOME and KDE (and have a lot of components that a lot of people can't or won't use), develop your own component standard (how many ways can I say bad idea?) and carry two sections, one with KDE components and one with GNOME. Oh yeah... You could say that your repository is less for components than libraries: still a worthwhile project.
What I would really love to see is you foster development of new software and adaptation of existing software to work within a given component framework. I dearly wish GNOME and KDE would standardize, but it looks like they won't. I really don't know which is better: GNOME seems better developed, KDE seems to likely engender better support in the OSS community.
Anyway.. Those are my thoughts, do with them as you wish. Let me say that I would LOVE to see a component archive -- but I think it's going to have to come with standardization of some kind. Guys: we have got to agree on a common standard environment, including at least interoperability.
One thing you could do is this: develop some components under straight CORBA, avoid doing GUI components altogether for the time being (until some standards develop), and hope that KDE actually continues with CORBA now that they've partially "dissed" it.
-- Slashdot sucks.
While I realize that /. is primarily a linux-related area, I would like to call attention to those fledgling programmers who would like to develop open-source software on other, more propriatary platforms. I use BeOS.
:)
While I realize that C code is C code, I would just like to mention/propose that other OS-specific code be accepted also. I have no clue how to impliment a BWindow()
"AOL, CIA, NSA, whatever, they all collect information, and they are all out to screw the american public"
have you checked out Abisource? I think that's more or less the kind of thing you mean.
They are working on productivity apps, but I believe they also have a repository of useful code that would fall under the "components" heading.
Of course, I could be wrong, in which case it would be just swell if somebody would correct me...
--
grappler
Vidi, Vici, Veni
A few issues:
Once a component goes into the repository, what's the best way to keep backwards compatibilty?
Who controls versioning for each component, and decides what goes into it?
Most coders hate writing doc. How do you maintain consistancy for your docs?
Someone pointed out that you need a component model; there's at least one group that's working on that (name escapes me at the moment).
Which languages do you support? Do you have interoperability between languages? What do you use now? Corba? It's going towards the JavaBeans model in the next version ....do you go for that?
Those are just a few of the things to worry about.
Don't get me wrong, I think this is a great idea. It's going to take a LOT of work to coordinate.
I think the best way to handle this is to get a very small group (four or less) people together, and decide these, and the other issues that will arise. Don't use any more people than that...if you do, the committee will argue until they're blue in the face, and you'll never get anything done.
What if you could take the CPAN system's support for automated download and install of modules and apply the concept to, say, Java environments in some of the following ways:
In other words, making a freshmeat not for direct human access, but for automated machine access and autodiscovery.
As has been mentioned before:
There's no reason for this to have to be GPL-only.
Yes, freshmeat is a bunch of links to a bunch of software.
Also:
Maybe 'component' wasn't the best choice of words here. How about 'reusable code', or 'useful functionality'? Is that a better buzz-phrase, guys?
There are already central archives. They are called public, anonymous ftp sites. Like metalab.unc.edu or ftp.cdrom.com.
Feel free to use one of those, but all you really need to make is a database with info about what is available where, under which license. And Freshmeat already does an okay job of that, at least.
So go make your own Freshmeat with an archived repository, license info, and links.
Comments?
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
If its public domain, couldn't they just GPL it? Then, even if they do play the scrouge, your code is up for use. That kills off the reason you'd make it public domain rather than GPL.. but the point of making it free was to allow anyone to do with it as they pleased.
Anyway, I doubt that only GPL code would be allowed, just anything that complied with OSI. A few reasons... much of anything done turns out to be for ego, it would reduce the ammount of code/apps submitted (thus reducing the quickness of success), and with the notion that open source = higher morals (and its not even ==), people would bash them for only GPL code (they might be all GPL-lovers, but its the social trend). The FreeBSD driver site that was announced a few weeks ago went BSD when people whinned (Linux people only I believe.. I didn't see anyone say "I'd love to have them support OpenBSD.. would make my life a lot easier." And of course.. the next thing I saw after the change.. "will they support Darwin?"
So never fear.. if they build it.. they'll take your code for right or wrong, but they'll happily take it.
"Open Source?" - Press any key to continue
So, what's the point of the proposed repository? I guess, it wouldn't be very useful to implement the functionality that we already have all over again. What would really be needed is a site that makes it easy (especially for less experienced programmers) to find the library (or component, if you insist) that they need.
A search on freshmeat isn't terribly effective if you do not already have a rather clear picture of what you are looking for. In other words, it would be helpful to provide an index that makes it easy to find the functionality that you need. The index could then for example point to the freshmeat entry of a selected software component. Organising such an index in such a way that it is easy to navigate is definitely a challenge, but it would probably also be very helpful.
Chilli
-=- Just a random lambda hacker
Only I want to take it even further. First off, let me reference two previous posts on SlashDot: 'Its the API's Stupid!' and 'Again: Its the API's Stupid!'. In those posts I made the case for developing an API that was both an Open Source Component development/delivery/runtime system and a set of standard Components built with/for it. Quote from those posts:
"We need a fast, simple, powerful and complete Open Source solution for component based development. An API (preferably a cross platform one) that you can write code to in any of the most popular languages. And it must have a reference implementation that is open source with a GPL license. It should be highly Object Oriented and should provide base objects for every major Design Pattern. It should front-end the OS so completely that you can write a new OS which directly provided the relevant API's (making it a kind of Meta-OS). The API itself should be open and there should be a standards committee that isn't loaded with representatives from the big companies. Plus, no-one is penalized for producing a non-compatible version (other than the fact that compatible versions would probably receive a greater market share)."
Also Quote:
"I have been working on my own for some time to develop the beginings of such a standard. A kind of hobby for me. And I know there are plenty of people out there who will claim such a thing already exists in (choose one) PERL, Python, Smalltalk, Gnome or some flavor of the month. I don't think any of those things meet all the criteria of the environment I want to see, but I can state one thing rather confidently... Until we pull together a produce such a thing the Open Source movement will have a lot of difficulty competing against Sun and Microsoft in the Business Systems space. "
One person sent me a pointer to Bamboo, an Open Source project to develop a component runtime system (partially using Mozilla code, which is cool). Others have referred me to CORBA and even ZOPE. Personally I think all of these things are good (although CORBA may be too heavyweight). But none of them go as far as I would like.
Although I want to see real code as well, I think the process should start the way any good development process should start: With a good design. With an architecture. I am currently calling this the 'COA' or 'Common Object Architecture'...
In one of my design documents I describe it this way: "A shared set of class and interface specifications that may be implemented in any language and/or with any distributed object methodology. The COA is a Specification, a Platonic Ideal - any implementation of the architecture is coupled to the COA only to the extent to which it correctly exposes the interfaces of the architecture. The intent is to create a standard system workspace for programmers to use that transcends operating systems and programming languages. Furthermore the COA is intended to facilitate the creation of distributed applications where the objects may reside on any system on a network, but look like they are local to the calling application."
Then, once the design is complete, we throw it open for development. Much like a protocol, anyone can develop both open and closed source versions of the COA. Of course I expect the Open Source versions to get more use...
And these versions might be developed for any platform and in any language because one basic part of the COA would be a split of the class definitions into two types: Native and External. Native classes have standard method calls that may be directly implemented in whatever language/object environment is being used. External classes may only be accessed through a common messaging interface defined in the COA Messaging library.
This means that Native classes are generally 'synchronous'. They return control to the calling code immediately, allowing them to be implemented as 'In-Process' and 'In-Thread' with the calling code. In most cases Native classes will be fairly small grained 'tool' classes used as components in building larger, more functional, objects.
External classes are extremely large grained 'Actor' objects that expect 'prompts' and execute 'behaviors'. They operate asynchronously, the only way that calling code can know they have completed a requested function is when they return a message indicating this fact. Although an External class may actually be implemented to run in the same process space and even in the same thread space as the calling code they function as external servers where the calling code is the client. In many cases the calling code may only be connecting to a lightweight message interface class which front-ends an External class running on another machine entirely.
These two types of classes exist to provide an opportunity to "Have our cake and eat it too." The Native classes may be bound at compile time (for those implementations that support it) and will operate with the least possible amount of interface overhead. Plus they make it possible to create implementations of the COA in environments that do not provide for multi-threaded programming. Meanwhile the External classes allow for disconnected operation and execution across system boundaries with the least amount of overhead possible.
Sometime soon I expect to set up a discussion group on this topic. Anyone interested? Email me and let me know...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
This is a GPL'd system written in a GPL'd language that's available on a wide variety of platforms. Why reinvent the wheel to prove that we don't have to reinvent the wheel? :)
Gates' Law: Every 18 months, the speed of software halves.
Interestingly, the Delphi community has produced VASTLY more components, many free or quite inexpensive (with source available) than the much larger groups of people using VB, C++, etc. The only other community with such a large set of components is Perl (CPAN).
Just one category, database access components, sports over 50 entries.
(minor plug warning:) I operate a web site that contains extensive information about database access components:
http://kylecordes.com
It's a lot of work to maintain my list of 50 or so products... maintain a global registry of similar detail would be full time work for several people.
http://www.rocketaware.com/
Includes special sections for GNU software, BSD man pages, FAQs, AskSlashdot (back to the beginning), Programming related books. Even has links to cosource.com, dmoz, yahoo, fatbrain, amazon.
Over 15,000 off-site programming related links. You must check it out. A single idea just like the one that started this thread was discussed about 18 months ago. This is the result.
On tap: (coming up) on site discussion, all of the unc metalab linux archives, and anything else we think of or get suggestions, or gets submitted.
An interview with Bowie J. Poag just went up today on linux.com. Here's an excerpt:
linux.com: What's System 12 all about?
Bowie J. Poag: System 12 will be a resource stockpile for Linux application developers. For lack of a better buzzword, we don't really know what to call it yet, but the basic premise is this: System 12 (hopefully) will do for Linux application development what Themes.org did for windowmanagers. We're going to be offering a series of free "component toolkits" for developers to include in their own work. In exchange for using our work, we will be offering them free hosting space on our server so they can showcase their work to the community.
Visit the System 12 site if you're anxious.
The internet is fine for a distributed, poorly catalogued repository. If, that is, you know where to look. As a casual (i.e. non-professional) programmer I haven't the slightest idea where to start if I want a GPL module to do task-x in any language other than Python or Perl. Sure there's lots of places for code but I've had to wade through commercial garbage for hours and still not find anything useful.
I'd like to see a site that kept material up to date and indexed by task and by language. And not just say basic but also who's version of basic (or C/C++, Pascal, etc). Something that could say to the green programmer "What do you want? We have this abailable for platform X, language Y, etc."
If what I said is nonsense,
I'm making a point with it.
If what I said makes perfect sense,
you obviously missed the point.
If the only language is C++, then your project will be rejected because some people prefer to use C, Objective C, Scheme, Perl, Python, and Eiffel.
If you plan to use many languages, then you probably have ONE choice for a structure on which to build this, namely ILU (Inter Language Unification). Unfortunately, that leaves you with a set of data structures that are to some extent a "lowest common denominator" of the things supported by all of the languages.
In effect, the only choice for the sort of "componentizing" that you're describing is some variation on CORBA. You probably need to get a copy of the Henning/Vinoski book on CORBA, and to start writing chunks of IDL to represent all the sorts of interfaces that you want to be able to have "published."
Unfortunately, there's still an impedance problem, as:
If you're not part of the solution, you're part of the precipitate.
A CPAN like mechanism would work well for languages that have very well defined, unambiguous specifications. Perl, for instance, behaves pretty much the same way on all (at least Unix) machines. Java and Python, as well as most other "interpreted" languages also share this characteristic.
C and C++, being much older, with more carryover "baggage", however, do not have the luxury of a fully specified language definition. In the ANSI spec for C/C++, there isn't even a set size for the basic data types! All that is required are various ambiguous properties such as sizeof(long) >= sizeof(int) >= sizeof(short)
A generic C/C++ code repository would face much difficulty in maintaining portable code that would just work for anyone, given the nature of these languages. As far as Perl, Java, and Python go, there are already many code repositories available: CPAN, Gamelan, and Python.org all contain links for downloadable "modules" for these languages, repsectively.
The example that I keep citing (and nobody has ever done anything to bring to fruition) is that of the calendaring systems. GNOME and KDE both have calendar programs that "grok" the iCalendar specification, but only partially. In particular, iCalendar was designed to allow "Calendar clients" to connect to a "Calendar server" that could provide schedule information for multiple users.
What they should do is to define a CORBA interface to talk to a Calendar server; by having common IDL that would be free of ties to any GUI there could be one implementation of a Calendar server that both the GNOME and KDE clients would talk to.
This is much same idea as the notion that any sort of web browser can talk to an HTTP server.
Don't be so sure that KDE has "dissed" CORBA as dramatically as you're thinking; what they have concluded is that running raw GUI calls through CORBA to implement compound documents is quite ridiculously inefficient. Note that the GNOME guys have largely concluded the same thing. (ORBit appears more efficient than MICO, so GNOME may get away with doing more with CORBA than KDE can...)
The point is that CORBA has enough overhead involved that you don't want to be shipping around tens of thousands of CORBA calls per second.
On the other hand, using CORBA to request:
... That a text editor be invoked to edit a file, ... That a document, specified as a tree, be submitted to a printer, ... That a bundle of configuration data be retrieved
all represent areas where there's large enough "granularity" that CORBA can be useful.If you're not part of the solution, you're part of the precipitate.
It strikes me that a lot of Open source code is out there in CVS repositories, much of it available by anonymous CVS. It also strikes me that the maintainers of this code *want* to maintain control of their repositories to make sure that things like backups happen to their satisfaction, etc, so it seems unlikely that a *centralized* place for repositories will appear, and even if it did, it doesn't seem too appealing. The decentralized disorganized spread-out chaotic highly-excessively redundant nature of the current state of things probably has something to do with its success.
So, back in the old days, there was archie, which used to go out and search FTP sites anonymously and make a giant index of what was out there. Now we have web crawlers.
How about something like archie or web-crawlers except it goes out probing port 2401 (cvspserver) and catalogs what it finds (maybe does a "cvs co -c")
An extension to CVS to allow a sort of description of what's in the repository (freshmeat style?) to be probed might be cool.
i.e. maybe a "cvs -d wherever whatchagot" command, that could just spit out the contents of some files in CVSROOT, perhaps without even requiring a "cvs login" And a standardized anonymous CVS login and password might help...
Hmmm. Maybe I'll propose this in info-cvs@gnu.org. But it's kind of a chicken & egg thing. Without the cvs-indexer-robot, what use is the new command, (and everybody would need to upgrade to the newer CVS server) and without the new command, the web-indexer isn't really feasible.
Hmm. Maybe I'll just implement the damn thing (the cvs mod, not the cvs robot, I'll leave that to someone else with the bandwidth and the hardware to do it with.) and submit the patch to bug-cvs@gnu.org...
Later, got to look into some code!
Bang the head that doesn't bang!
CPAN depends on testers (of known quality) to approve items. Not every language has as centralized a community. This may mean giving people of known quality temporary autocracies to recruit a pool of testers of known quality. After the high standards are set, a more democratic (or anarchist, depending on your POV) can take over.
Gates' Law: Every 18 months, the speed of software halves.
The usage of the term ``General Public Virus'' all but confirms it. Serious usage of this term indicates a lack of understanding, and is strongly indicative of the notion that the person using said term dreams of software that they may not only use, but abuse as they see fit (and, indeed, extends this dream to cover all software ever created.. apparently this isn't just restricted to people who deal in warez anymore). No one is forced to GPL their software, and if you wish to build your work upon the work of others, you must abide by their licensing scheme. If you don't like it, do it yourself. It's rather simple.
Complaining that the GPL doesn't achieve your aims and objectives very well is ludicrous. Just don't use it. What can not be argued (reasonably) is that the GPL fails to achieve its own aims and objectives. It has done so with flying colors. So, if you like the GPL, use it, if you don't, then another license will suit you better. Complaining that you can't turn GPL'ed software against its intended goal is paramount to complaining you can't enslave people anymore.
The other obvious hole in the logic presented here is the notion that you can't use GPL'ed code in a public domain software package. This isn't entirely true. Public domain means that there is no copyright license. You are free to fork the unlicensed software package and relicense it. So, while it is true that you can't use GPL'ed code in public domain software and still have it be public domain (it is now under a copyright license -- at least your fork of it -- the GPL), it is not true that you can't do it at all. You could relicense it under any other license as well. Of course, the original would still be public domain, but your ``distribution'' of it wouldn't have to be.
~ Kish
"Write your own and don't whine that you can't steal from us."
:-)
It's not stealing, it's sharing code with my friends
A Government Is a Body of People, Usually Notably Ungoverned
Why would it matter to a consulting firm if they have to release their code to the client under the GPL? They're not making money from selling code licenses, they're making money by providing services to the customer. Of course, they might also build up an internal repository of components, but if they can get a vast number of components for free, they might consider it worth giving up the advantage they get from having proprietary code for that advantage of having all this free code available to them.
For consulting firms specialised in niches, this might not work out to their advantage, but for most consulting firms, I would expect it to make sense. Though I don't have any experience with consulting firms and their code libraries, so I might be way off, but I suspect I'm not for most outfits.
Well, you can distribute perl under the GPL or the Artistic License, at your option. But for what you want, you'd be better off using the XFree86 licence, which is compatible with pretty much all the others. Or better still, just release it into the public domain, and people can relicense it under whatever terms they wish (BSD, GPL, proprietary, etc).
Bear in mind that if you allow people to distribute the code under the BSD licence, you also allow them to distribute it under a proprietary licence, since the BSDL allows this.
-- Ed Avis ed@membled.com
What is happening with the Trove project?
-- Ed Avis ed@membled.com
Primarily for use in C, but bindings exist for numerous other languages, too.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
You can't slap a copyright on a public domain work as is, but as soon as you modify it somehow, you have copyright to the modified work, and then you can GPL it. You can, e.g., simply add a GPL copyright notice in every file, and then license the work under the GPL. So it is certainly possible to take public domain source and put it under the GPL without even changing the actual code.
Many people would, of course, find this to be offensive, but that doesn't mean you can't do it.
There is nothing about interfaces that require objects. You need user-definable types, but there are very few typeless languages, so that's not a problem. As long as you have types, you can specify the signatures of every public function, which is what is needed. So there wouldn't need to be anything OO about it.
Actually, you don't really need user-definable types, either, but they make it a lot easier.
Thank you for responding Kent!
First, let me say that I am actually considering Bamboo as one of the underpinnings of the COA. As you pointed out -- in this case being lightweight is an advantage. Actually a huge advantage.
But let me quote from my original post (referring to Bamboo, Corba and ZOPE): "But none of them go as far as I would like." As a basic technology underlying the COA Bamboo is very nearly perfect. Much as the ZOPE Object Database design (ZODB) is nearly perfect for COA persistent storage. Only thing is, these are peices of what I see as a larger whole...
The real point is that I want to design first and develop afterwards (what a thought!). Not being a foolish egoist, I have every intention of incorporating any existing technology that would work as part of the whole. And I do see Bamboo as possibly filling a specific role, both in code and architecture. I would welcome your help in making this so!
So what do I need right now? Something you are probably doing anyway: Architectural documentation for Bamboo. Preferably with UML diagrams and with more detail than the overviews I found drilling down from the Bamboo web site. And I would really appreciate your active participation in the COA effort. Everyone involved has real jobs of course, and so we will probably proceed in fits and starts. Plus there is the usual possibility of the whole thing just fading away. But I can guarentee you one thing; this is an idea whose time has come. If it isn't the COA it will be something else.
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
The question that immediately comes to mind is how to organize the code. CPAN is PERL-specific, and other repositories tend to be similar in terms of supporting a single language.
.02
On the other hand, the purpose of the proposed repository is to support the distribution, improvement, and archiving of GPL code. IHMO the specific language should be secondary; i.e. the repository directory for a given type of network interface would contain C, C++, Java, Perl, and other code.
Confusing? Yes, somewhat. There would certainly be disjoints where there is no equivalent code, and the repository hierachy would have to be somewhat general. But doing so would have the implicit effect of encouraging porting, cross-platform development, and ultimately support sharing and development of GPL code in a manner that's not been done before.
-just my
I think not...(*poof*)
Why should it bother *you* that *my* friends don't share?
Software should not be owned. If my friend asks me to make a copy, it would be wrong to refuse. By putting a copyright on the software, you are asserting ownership over it, and denying me my natural right to share it. People not only deserve free software, they deserve software without conditions.
A Government Is a Body of People, Usually Notably Ungoverned