Todd Fabacher wrote:
> I think we can find a solution. *Richard*, this sounds like the
> perfect open source community project. What do you think?? We
> can host the stuff on GitHub, but create an interface within the
> IDE with an online DB that can be queried. we could slap a simple
> RestAPI on it and people could query it to get helpful code
> snippets and usage examples and complete App examples.
Yes indeed.
A central index for all components, regardless of type or license, is
essential for platform growth and for serious development.
For open source projects, IMO GitHub is an ideal location. But it isn't
the only such service, and there are good projects on many services, so
probably best not to limit the index to those hosted on only one.
For proprietary projects the range of share locations may be even
broader, since there's no requirement that the location provide
collaboration tools supporting public contribution.
There may be many good reasons why a developer might prefer to share a
resource through any number of other sites, or even their own. As long
as the resource is check-summed and the domain is ensured with a good
SSL cert, I don't have a lot of opinions about where a shared resource
physically resides.
Beyond basic file and domain integrity, it seems to me it doesn't matter
so much where the file lives, as long as an index exists in one
well-known location to be able to find it from.
An ideal index could allow good searching via a minimum of these fields:
- Resource name
- Category and perhaps subcategory of functionality
- Resource Type (external, widget, library, template, etc.)
- Author/Publisher/domain
- Date of first release
- Date of most recent release
- Minimum compatible LC version required
- License type (GPLv3, GPLv2, MIT, BSD, proprietary, etc.)
- Keywords in full text of title/name and description
- Vendor-supplied tags
- Crowd-sourced tags that any registered user of the system can add to
It needs to be API-driven, so we can build a UI for use in the IDE,
write our own ad hoc tools for finding and updating components, and
enjoy the SEM benefits of having the index also available in the web.
With that I could, for example, easily search for an image filter
library made available under GPL-compatible license and instantly find
Tom Bodine's excellent toolkit in one move.
Background
----------
Many of us saw a need for resource sharing, and the ease of delivering
that right in the IDE, from the moment we saw the old MC Examples stack,
before the turn of the century.
I found that download-n-go very inspiring, and eventually I made the
time to deliver the first publicly-sharable index in the modest Stacks
section of RevNet in Dec 2003 (since renamed as "LiveNet").
The following year RunRev Ltd. made RevOnline as a more complete
solution for our community, to share not only stack files but also
externals and code snippets. (To support the goal of a single index and
also relieve myself of potential security concerns, after RevOnline
premiered I restricted and later removed the ability for public
additions to RevNet.)
Later on RevOnline's upload went out of commission for a few years, and
in response several community efforts sprung up, including a nice
index-focused offering from Shao Sean.
None of the community-driven repositories or indexes ever really gained
critical mass, because during that span of years there were periodic
announcements from RunRev Ltd. (now renamed LiveCode Ltd.) that they
were going to complete RevOnline to restore its upload capability,
refine its listing (e.g., it isn't sortable), and expand its
functionality to include more resource types (first externals and now
widgets).
RevOnline's account management and upload features were eventually
restored. But during that time it also became renamed, rather
variously, so that today few people can piece together that "RevOnline",
"Sample Stacks", and "LiveCode Share" are all more or less the same
thing (further muddied by that repo containing script snippets, yet a
different facility named "Sample Scripts" is entirely separate from
"RevOnline"/"Sample Stacks"/"LiveCode Share").
In addition to picking one name and sticking with it, as reported
earlier in this thread apparently the file upload feature needs further
refinement. And at a minimum it should probably be enhanced to include
indexed fields for license type and to support widgets.
Meanwhile, other tools have demonstrated the value of a central index
with things like NPMJS for Node, PyPy for Python, CPAN for Perl, CRAN
for R, the listings of modules, themes and plugins for Wordpress and
Drupal, and others.
Many of those repositories are maintained by their respective communities.
Options Going Forward
---------------------
There's no question of the need or the value. The only question seems
to be: should this be a community project, or one created and
maintained by the company?
There are benefits both ways.
One thing I try to be sensitive to is that the C++ expertise needed for
engine work is both essential and very rare in our community outside the
company, and that nothing in this specific index project requires C++
expertise.
Indeed, I believe it's safe to say that the short supply of engine-level
expertise seems a very good reason the company hasn't yet completed
what's needed for a truly useful index of third-party resources. The
engine is a demanding bit of work; the v8.x and v9 builds have been very
exciting for us, and a tremendous effort for them.
With that sensitivity to allowing the C++ experts to remain focused on
C++ engine work where practical, I might be inclined to support your
suggestion that this index may best come about as a community project.
That said, there may be security, packaging, and other considerations
which might benefit from the insight of core dev team members.
The one thing I can say with confidence is that any community effort on
this would need to have the full public blessing of the company to be
successful.
Without that, it risks the same fate as earlier attempts, where
community-managed projects die from underutilization as people wait for
something from the mother ship.
Personally I don't have a strong opinion about whether such an index
should be built and maintained by the company or the community.
It may be good to get guidance from Kevin and/or Mark on this first, and
since they're both pretty active on this list perhaps we'll hear from
them when the weekend's over.
--
Richard Gaskin
LiveCode Community Liaison
rich...@livecode.org
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
