Open-Source Component Repository? 170
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.
Counter examples... (Score:2)
The CPAN PERL modules.
MiscKit. gnustep.
To name a few off the top of my head.
Good idea! (Score:2)
Not Freshmeat (Score:2)
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.
CPAN Works nicely for Perl... (Score:2)
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.
Sounds good (Score:1)
A new site perhaps? GPLStuff.com?
-----------
"You can't shake the Devil's hand and say you're only kidding."
CPAN Anyone? (Score:2)
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.
Re:It exists... (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Why Open Source (Score:2)
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.
GPL? (Score:2)
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.
ive had a similar idea - didnt get posted tho. (Score:1)
Source Code Verification (Score:3)
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. :)
Sounds like C Snippits (Score:1)
IIRC, they're still on the web (though not as comprehensive as I remember them). http://www.brokersys.com/snippets/ [brokersys.com]
they'd be a good start for something, in any case. There are lots of goodies (though some really old, irrelevant stuff too) in there.
Hmmm... (Score:1)
Then I realized that I could in fact use such a repository after all. Lately I've been thinking about looking into writing device drivers. I've never done such a thing before, and wouldn't know where to start (except searching for some basic knowledge on the topic). If I could go to this hypothetical repository and grab a few device driver templates, that would go a long way towards my education. I'd probably still end up building them from the ground up, but at least I'd have some training wheels to use before reaching that stage.
That's that I think would be most promising about the repository idea. Not being a source of code that I can rip and put into my own projects, but rather a source of examples to learn from. The more I think about it, the more I like it.
Duh... (Score:1)
Maddog would seem to agree... (Score:1)
He brought this up as a very understandable example of the value of open source in general... Lots of companies develop tools and components which are not really part of their products - generic applications for doing standard boring business things. These companies wouldn't hurt themselves by sharing such applications, at least from a marketing or legal perspective, and they're constantly wasting money developing these things when others already have them lying around.
I don't see why this concept should apply only to whole applications and not to smaller code fragments (e.g. a good hash table implementation).
Already dealt with... (Score:1)
I hereby volunteer to set up such a thing for Mason components... Easier than for C++ since Mason is innately component-based...
I had already planned on distributing Mason components on my site -- those that I developed at least... I think it works well to expand that idea...
Jon Frisby, Sr. Software Engineer,
Personal Site (MrJoy.com) [mrjoy.com]
Component Format? (Score:1)
around the area of an object repository. Not
just library implementations; most linux dists
have waay too many libraries that do far too little.
Perhaps we could build some kind of description
format, like which design pattern it follows,
dependancies, runtime costs, time complexity,
etc...
Something to think about.
--
Insanity Takes Its Toll. Please Have Exact Change
Re:Not Freshmeat (Score:1)
Freshmeat (Score:1)
It has a section for "License", I guess if you could search by that, or search for what you want and check the "License" field, it'd work perfectly fine.
Or, for the really lazy, write something that searches Freshmeat and parses the output if you don't want to do it the old-fashioned way. (i.e. reading it yourself.
---
pb Reply rather than vaguely moderate me.
Diversity of code (Score:1)
The problem with creating a single monolothic open source repository stuffed with functions and class libraries for everything under the sun is that people's needs are far too diverse. The current model, where tidbits of functionality for specific topics are maintained by various organizations considered "authoritative" in that field, has proved fairly effective. Some notable examples include netlib [netlib.org], libwww [w3.org], ARPACK [rice.edu] and of course CPAN [cpan.org].
I'm not sure what purpose would be served by bringing all of these various efforts under a single roof. They all have differing philosophies, goals, and styles. Some, such as ARPACK, are highly domain specific, and its maintainers are unlikely to care about "generic code repositories." The STL filled a very important niche, but having gotten the basic algorithms and data structures out of the way, creating a massive interdisciplinary code repository is an unachievable and perhaps undesirable feat.
Not a bad idea. (Score:3)
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.
What about other Alternate-OS users? (Score:2)
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()
Sounds like Abisource (Score:2)
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
A Question of Licences (Score:1)
Big issues just below the surface (Score:3)
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.
get more adventurous (Score:2)
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.
Re:Sounds good (Score:1)
gasp! hurry up and register it! _never_ mention a catchy phrase with
Very good idea (Score:1)
It would be very nice to have one common place for component/(C++ class) shopping. I think that the open source community by its nature would greatly enhance the quality of such components. For example, instead of 50 people writing 50 different Date classes for their individual projects, the effort could go into producing a high quality Date class. There are many people that could contribute their expertise. I'm sure there are thousands of developers more knowledable about re-entrancy issues than I am, and they could add their modifications to the code for the benefit of everybody else.
So next time that you need a drop down combobox with multiple selection and user defined icons for KDE or gnome.... or you need graphical speedometer component, you just might find it at the code repository.
Willy
Metalab (aka sunsite) pretty much does a good job (Score:1)
Another tack. (Score:1)
The repository specifies interfaces, [ie The Prototypes of the public methods, and the names of the public constants.] Individuals deposit implementations of the interfaces. The result: 4 different String's, which are interchangeable.
I know this is OOP dependant, but for this to work, objects or clusters therof are a neccessity (this last assert()ed without proof.)
I'm all for it!! ;-) (Score:1)
That way, Linux users won't have to hunt all over the 'Net TRYING to find the files they want. This is going to be more critical with the release of the Linux 2.4.x kernel the end of this year with its increasing support for USB (and eventually IEEE-1394) devices.
Complain all you want about Microsoft, but the fact that MS has a very good download library makes it relatively easy to do things like patches and upgrades.
I think Freshmeat should be converted to this, with FTP servers directly connected to the Freshmeat HTTP server for easy downloads.
I iterate. (Score:2)
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.
schools (Score:1)
Maybe the french open source senators (tm) could get funding to hire some gurus to lead the project too
Laurent
---
Re:It exists... (Score:1)
Re:It exists... but imagine the potential (Score:1)
Delphi has had sites like this for years and they are huge in both size and importance. For example, lets say I want my application to do Blowfish encryption. I do a search on the "Delphi Super Page" for a freeware with source blowfish component. And viola, 3 show up. They literally have thousands of components and several dozens uploaded daily.
If you want to see this for your self, check out:
main site:
http://delphi.icm.edu.pl/
or mirror sites:
ftp://ftp.cdrom.com/pub/delphi_www/index.htm
http://community.borland.com/homepages/dsp/
I'm not suggesting a copy of this site. I think the interface is awkward and there is a lot of shareware crap, but it has been an invaluable on many occasions.
There has also been other sites out there that had programming FAQ. Kind of a dejanews except dedicated to Delphi only. I think that programming *nix in general could massively benefit from centralized knowledge/component base.
But be warned. It is a lot of work to maintain sites like this. Several Delphi such sites have vanished for unknown reasons, such as www.delphi32.com and www.delphiexchange.com, among many others. The Delphi Super Page and Torry's Delphi page from Russia are the few good ones left.
Ozwald
Re:CPAN Works nicely for Perl... (Score:1)
Re:GPL? (Score:1)
We all owe a lot to the GPL, so quite your snivelling about it being a Virus and don't use GPL'd software if you don't want to.
Re:A Question of Licences (Score:2)
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.
Where's the glamour? (Score:1)
Not conviced (Score:2)
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
Re:GPL? (Score:1)
linuxberg? (Score:1)
./brm
Algorithms (Score:1)
Don't we already have this? (Score:1)
I think this would be an interesting challenge though. It's been my experience that in the commercial world, most components are either too limited because of the lack of source or too hard to use becuase they don't want you to have the source and they are too focused on being a "component" or "reusable" and generally end up sucking. It's a rare balance of ease of use and power that makes a good component. opensource throws all that out the window because you can customize and tailor pieces for your task and as a result not too many are focusing on producing just pieces. You have to do more work to get at the pieces but you can make them do what you want.
It should be an interesting experiment, if nothing else. It will be interesting to see what is "good" and what isn't. It will also be interesting to see the "component granularity" that is popular. (the classic example is to have reusable hashtable, tree and list classes but those are very easy to implement and don't buy you a lot by reusing them. An HTML widget or an RTF widget, on the otherhand, is a substantial amount of effort and can buy a lot if they work nicely.)
Good idea as far as I'm concerned... (Score:1)
No kidding (Score:1)
--------
"I already have all the latest software."
Try gjt.org (Score:1)
I have been saying this for a long time now... (Score:3)
Only I want to take it even further. First off, let me reference two previous posts on SlashDot: 'Its the API's Stupid!' [slashdot.org] and 'Again: Its the API's Stupid!' [slashdot.org]. 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 [watsen.net], 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 [zope.org]. 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 [mailto] and let me know...
Jack
Why not modify CPAN? (Score:5)
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? :)
Delphi components - LOTS of them! (Score:2)
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 [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.
Re:GPL? (Score:2)
If this is the behavior you want with the GPL, then BE PROUD OF IT, and stop snivelling about it not being viral. Stand up and proclaim to the world that you use the GPL precisely because it's a viral free license!
But the topic at hand is a component repository. If everything in it were GPL libraries, then only GPL apps could use it. Not even LGPL libraries would be able to use it! I'm assuming that this repository would be for the whole community, not just GPL-only coders.
GPL vs LGPL? (Score:1)
This isn't viral behavior but there is a bandwagon or "me too" effect that is associated with the GPL.
Re:Not a bad idea. (Score:1)
It is platform neutral. Supports local and distributed operation. It is a mimic of the JavaBeans standard which is really very cool except for the poor performance
It could be a contender for use in such a repository, as well as, GNOME and KDE.
Already in the works! (Score:1)
Re:VERY BAD IDEA!!!! (Score:1)
Secondly, the lack of a user name tells us a bit more about this in'duh'vidual.
Lastly, The whole GPL idea is to keep people from patenting the idea published. We write the code, or we modify the code written by others to suit our needs. Patents are pointless through this method. Nobody's getting very rich, but we are making one of the best OS's out there even better by pulling ideas from programmers all over the world. Nobody has even tried to patent any of these programs of code enhancements, as far as I know.
By the way, I'm sure that it would've been posted on /. if somebody had tried it...
Re:A Question of Licences (Score:1)
Perhaps think about submitting them under a MIT like license. No one would be able to change the license, but they would still be free to use whatever license they wished for any derived code.
APT RPM and other such things (Score:1)
It's More Than Just Software (Score:1)
It is important to realize that projects are way bigger than just software. There are jpeg, midi, HTML, txt, etc. files that need a GPL'd component repository too. In fact, any work that can be copyrighted needs to find a friedly home in the Component Repository.
The Component Repository needs to be a home for artists, musicians, mathematicians, architects, philosophers and poets. Let's see, did I leave anyone out? Oh yes, programmers too.
Already exists.... (Score:4)
http://www.rocketaware.com/ [rocketaware.com]
Includes special sections for GNU software [rocketaware.com], BSD man pages [rocketaware.com], FAQs [rocketaware.com], AskSlashdot [rocketaware.com] (back to the beginning), Programming related books [rocketaware.com]. Even has links to cosource.com, dmoz, yahoo, fatbrain, amazon. [rocketaware.com]
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.
System 12? maybe (Score:2)
An interview with Bowie J. Poag [linux.com] 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 [system12.com] if you're anxious.
i lust moderator points... (Score:1)
Re:It exists... not really (Score:2)
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.
The Universal Impedance Problem (Score:2)
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). [xerox.com] 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:
Re:CPAN Works nicely for Perl...But not for C! (Score:2)
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 [cpan.org], Gamelan [gamelan.com], and Python.org [python.org] all contain links for downloadable "modules" for these languages, repsectively.
Build GUI-free CORBA SERVERS (Score:4)
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.Re:GPL? (Score:2)
It is different from a virus, where an executable is passively infected without you knowing it.
Therefore, by the nature of a virus, the GPL is NOT viral. If you insist on calling it a virus then I guess it must be a virus that depends on manual infection thru the hand of programmers.
Try to find a virus behaves just like that!!
Anonymous CVS + CVS extensions + CVS robot prober. (Score:2)
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!
Possible flaw (Score:2)
Trove Project (Score:1)
1. Great Idea!
2. Can we break up existing code into pieces and organize them? There is a lot of it out there in all the other Opensource projects
3. The infrastructure and ideas are similiar to the Trove Project (which is similiar to Freshmeat)
http://www.tuxedo.org/~esr/trove/ [tuxedo.org]
That's all
Who uses components and what license do they want? (Score:1)
I think the only way that something like this would work is to allow any type of license.
Having said that, I think it's a great idea. Personally, I've dealt with RogueWave [roguewave.com] components a lot, and I'm not impressed, even if they have started releasing Linux versions :) I think open source could reach their mark very quickly.
Re:GPL? (Score:1)
I've got it! I'll write the incredibly-useful "Include IO Stream Library" (which won't even compile), put it under the GPL, and anyone using that line of code will have to release their product under the GPL?
Re:GPL? (Score:1)
How about open source test plans/cases/scripts? (Score:1)
Re:How about open source test plans/cases/scripts? (Score:1)
Hmm, why not utilize the /. model? (Score:1)
Someone could submit an object/component to a team of people who would weed out (loosely) the duplication and plain useless things. These people could be picked by a vote of peers or some such method to establish a core of competence that the community at large trusts. Once it passes the initial quality check (one or more times) it could be up for a peer moderation style review.
When searching for a particular object you could set a quality threshold on your search. The higher the threshold the less likely you may be to find something exactly like you want, but the code you do get should be of high enough quality to impress the people who used it and rated it, in fact may be built well enough to allow you to modify it to suit your needs, maybe even to the point of creating something which may be of value checked back into the moderation system as a new object.
Re:CPAN Works VERY nicely for Perl... (Score:1)
Get the cpan module. It gives you a cpan command shell. Then type in "i /Gtk/" to get a list of all Gtk related stuff. Type "install Gtk" and it downloads it, compiles any parts written in C, installs, and than tests it for you. Also reminds you of what modules are out of date and updates them for you. Gotta love it!
Repository == Internet? (Score:1)
Re:Source Code Verification (Score:1)
Though I can't see many hackers wanting their contribution to the Open Source community being reading/reviewing code rather than making/modifying it.
It would be better without the GPL. (Score:1)
Here's an idea: rather than use the GPL for all the components, use a BSD/Artistic style license. Why? The GPL prohibits the code from being used in classic "cathedral" closed source projects. Why is that important, you ask? Well, if there were enough free (speech and beer) libraries do, oh, say, anything on Linux or *BSD, they suddenly become a much more attractive development platform than they already are. Time to market and cost of development drop through the floor. Linux and BSDs market share shoot through the roof as they become the preferred developer platform... since it's so damn easy to write code for a platform with extensive libraries.
And the upshot of it all is that it means less messing around with Microsoft products and more jobs working in the environments we love!
--
Re:I have been saying this for a long time now... (Score:2)
Hi Jack,
As the architect of Bamboo, I am very honored
that you have listed my project along side
CORBA, but am also very interested in how/why
it doesn't meet your needs.
I'll be the first to admit that Bamboo lacks
some of the features found in other component
frameworks, but I consider that a strength. As
I see it, all the kernel (user space) must do
is load and unload code, downloading it from
the network as needed (to resolve dependencies).
All other functionality (which you desire) can
be loaded as required. This enables the Bamboo
kernel to remain small (186Kb compiled) and
interoperable with existing wiring standards,
remoting standards, programming languages, and
VMs. Case in point, I run programs that have a
C++ engine (for performance), with COM wrappers
(actually Mozilla's XP-COM) for versioning, a
Java AWT based GUI, and Python/Tcl/Perl scripts
all in the same process address space!
In summary, like yourself, I was not satisfied
with existing options. What I have developed
is a practical, easy to use (based on user
comments), cross-platform mechanism for loading
code in/out of a process's space, regardless of
the programming language. While Bamboo is a
powerful mechanism on it's own, I strongly
believe that users should augment it with other
technologies to solve issues such as safety
(as in MMU, not authenticode), versioning,
remoting, reflection, meta-programming, etc.
So, what would you say about using Bamboo to
develop the COA on top of?
Sincerely,
Kent Watsen
http://watsen.net/kent
Obvious bait.. (Score:3)
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.
System 12, components, and ideas. (Score:1)
Just to clarify a few things....
A) The interview I gave with linux.com took place yesterday afternoon. Apparently, this Aiken guy probably read it when it was posted earlier today and decided to apply the same idea to sourcecode in his post to Slashdot. Ideas dont hurt anybody, so quit railing on him.
B) The sort of thing we're doing at System 12 doesn't encompass code-based components. Sound, graphics, and font component kits, yes..but not code.
C) This idea isn't new (or unique) and I certainly cant claim to be the originator of the idea... In my case, i'd been kicking the idea around for a good 2-3 years before finally having the opportunity to have a go at it this summer. However, as many people have pointed out, other people have been similarly kicking around the idea for quite some time, it appears.
Bowie J. Poag
damned license incompatibilities (Score:1)
I am a firm believer in Open Source for a number of good reasons of which we are all likely aware. The issue of licensing always comes up and often good Open Source code can't work together with other good Open Source code because of incompatibilities with licenses.
Often, a developer will release code under one license, and since s/he's the developer, also later release it under another license (it's proprietary and then GPL'ed, or Qt-licensed then GPL'ed, etc.). What would happen if, given that there are say 5 "blessed" Open Source licenses which happen to be incompatible with one another, a developer took his code and released a copy under every one of these 5 blessed licenses?
While this is not sufficient to solve incompatibilities, since the next developer on the BSD (say) branch adds his code in and just keeps it BSD-licensed; if everyone were doing it then the new code could be released under all the blessed licenses. This of course does nothing to make currently GPL'ed code compatible with BSD-licensed code, but is something gained by doing this for later code?
Is there a license that one could write which is something of a meta-GPL? In the sense of saying: "Code under this license must be redistributed under this license and under (blessed licenses 1-5)"... I'm not sure that's particularly cogent, but maybe someone gets my drift.
It's late enough that I can't tell if this is absolutely idiotic or somewhat sensible. Oh well, that's what flames and moderation are for.
Re:Let CORBA die (Score:1)
Re:GPL? (Score:1)
Re:Let CORBA die (Score:1)
If it's simple, and it's text parsing (XML), the open source community will have no problem mastering it.
If anything the "commitment" to CORBA is "disastrous" because it's likely to be outclassed and incompatible with quasi-proprietary commercial implementations, and thus worthless as a standard. Open Source works best with simple, baseline protocols - HTTP, DNS, and potentially XML-RPC.
--
A good idea, but... (Score:1)
First off, quality. Probably a simple voting system requiring a registration would suffice. Since it's not a religous issue (no freshly developed code fragment has the religous overtones of VI or EMACS) there shouldn't be too much ballot stuffing. Email registration takes care of the casual skript kiddy.
Simply rating the software on it's stability and efficiency would be nice. Comments on it's usability (how clean is the API) and the like would also be good.
Finding what you're looking for. A much harder topic indeed. Not many people go in looking for a Red-Black tree code fragment, so there probably needs to be some documentation on what functions do what you're after. Pointers to some excellent books on programming also apply.
How about Compatability? The whole thing is useless if every component depends on yet another different piece of software. (Which is why I'm so happy that aprintf is in glibc. That's a major improvement) Perhaps defining common APIs for common functions is a good idea? There's not too many ways to handle string classes, so if they were compatable, eventually they would be mergable into one well-done class instead of 35 mediocre classes. Identifying what is good and what sucks and standardizing should be the primary goal.
Lastly, Licence conflicts. If such a thing is done, to be truly useful it will have to be usable by everyone, not just GPL software. Nobody will contribute if we lock out all BSD style licences. My reccomendation here is that anything that's more then just a fragment of code be LGPL. Moreso, all of it should be linkable into a single LGPLed library. This avoids namespace bloat, as well as ./configure bloat. Code fragments? If you really want to GPL the code to free the first node of a linked list, you need to take a large, blunt object and beat yourself with it. Save the GPL for a PROJECT, leave simple coding examples public domain. Let the download counter of your snippet be your reward.
And as soon as such a thing exists, I've got a handful of code of varying utility I'd put in there. timer management, IO, buffering, whatever I've had to write. I'd like to clean out my attic and see if anyone else gets a use out of it.
--Dan
Re:Stealing (Score:2)
It's not stealing, it's sharing code with my friends
Thoughts (Score:1)
I can hear it now: "Boo! Hiss! Components have to be built on CORBA or DCOM or (name your acronym)!" Let me try to describe my view. Feel free to disagree!
The major benefits, in my view, of component-based programming are:
1. Components can be assembled with minimal effort.
2. The system scales well because additional hardware can simply be added.
3. Components are isolated from each other, so debugging is much simpler.
4. The developer has many choices of programming languages and platforms.
Which of these things can't be duplicated by a Unix script? Since multitasking is inherent and clustering is available, assembling a system using familiar Unix languages and multiple processes can be just as efficient as a CORBA equivalent. A Unix process does indeed have a component-like interface, though it may not be apparent at first: command-line arguments, the environment, pipes, signals, and sockets.
Therefore, it could be argued that the "component repository" is already on any Linux user's HD. Image manipulation utilities, formatted document generators, network protocol implementations, forms-based GUI generators, widgets, etc.
I'm going to provide a counterargument as well, however. An object-oriented component model needs to have easily defined and flexible interfaces. All Unix-based interfaces depend on a serialized stream of bytes. That is not appropriate when you want to send a polymorphic object!
Thought number two (much simpler thought and probably more useful): as long as we can first decide on a standard model (CORBA would be a good choice), we could begin building components out of the GPL utilities already out there. "wget", "ispell", XML processors, and more are good candidates.
Thought number three: The KDE people are already building lots of components. We have to build on their efforts as well as others'.
Licensing (Score:1)
Re:Who uses components and what license do they wa (Score:2)
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.
Re:Good idea! (Score:2)
It's much easier to standardize APIs then component implementations. The reason for this is that there is never a single best implementation for all circumstances. With standard APIs forking of projects is no longer a problem as long as the API is preserved.
BTW. what exactly is meant by a component here. Corba? A C library?
Re:damned license incompatibilities (Score:2)
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.
Trove? (Score:3)
Glib already does most of this... (Score:2)
Primarily for use in C, but bindings exist for numerous other languages, too.
Re:GPL, Public Domain & Fork-Proof Licences (Score:2)
Many people would, of course, find this to be offensive, but that doesn't mean you can't do it.
Re:Another tack. (Score:2)
Actually, you don't really need user-definable types, either, but they make it a lot easier.
Re: Bamboo for COA (Score:2)
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
organizing the code (Score:2)
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
Re:Stealing (Score:2)
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.