LC and OneSignal

[Richard Gaskin]

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
  richard at livecode.org