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 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.
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.
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.
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.
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.
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
What is happening with the Trove project?
-- Ed Avis ed@membled.com