Sample Stacks Stack in Livecode 8 - Gone ?

[Richard Gaskin]

Hermann wrote:

> This has become a theoretical issue about crossing bridges
> that we may never reach, projects of 2019-2021?

In my reading I see very much the opposite - here's what Peter wrote:

     As far as I know, we plan to introduce a package management
     system (with all of the capabilities that one might expect,
     such as version management, dependency management, checksums,
     cryptographic signatures, etc. etc.) as part of the delayed
     Extension Store feature.

     It won't be a small or easy job but it's very important that
     we get it right when we do it.  Don't expect anything that
     you can try out for a few months yet.

Given the 50 years of ACM literature on how software development almost 
always falls behind schedule for unanticipatable reasons, I can 
appreciate the temptation to read "a few months" as "a few years".

But on this one I'm more optimistic, for a couple reasons:

1. They've designed much of the Widget architecture knowing
    that packaging would be a critical part of it, so at least
    big chunks of the hardest part - design - have already
    been done.

2. They need this perhaps more than anything else in the queue.
    The company is heavily invested in Widgets as a solution for
    a wide range of development needs.  Without a packager there's
    no way to reliably trade Widgets.  Without a packager there's
    no Widget Store.  This is among the most critical must-haves
    on their to-do list.  It will get done, because so much of
    everything beyond it depends on it.


> RevOnline (the stack) was a nice tool, not really updated.
>
> Obviously and sadly it seems to be in the waiting room for the
> virtual trash, replaced by a slow website, although there are
> currently not thousands of files to organize but < 500.
> Nobody has time to optimize that.
>
> Life is short, we need NOW a solution.

It would seem simplest and less disruptive to simply leave RevOnline in 
place until its replacement is ready.  There may be reasons why it 
isn't.  It would be useful to find out what those reasons are before 
judging the merit of that decision.


>> R.G. wrote:
>> After all, a stack repository is for the community and comprised
>> of files made by the community, and maintaining a set of stack
>> files and a UI for accessing them is fully within the technical
>> abilities of our  community.
>> If it were seen as desirable for the community to take this on, I
>> see at least one way it could happen safely without an expensive
>> engine or format change.
>
> So please simply choose one way and start as soon as possible.

For myself, the decision is easy and I've made it, as I wrote in reply 
to Peter yesterday:

    Happy to have you folks do it.  And given the challenge of
    doing it well, I don't think anyone will mind waiting.

Some background on why I'm so easily persuaded on this:

Many years ago Ken Ray headed up a project that included contributions 
from more than a dozen other community members to draft a specification 
for plugins and other components to define metadata needed for updating:
http://livecodejournal.com/downloads/rip/ECMI_10.rtf.zip

In many ways it was a good draft, and more than a few plugin developers 
have adopted at least part of the ECMI spec at one time or another over 
the years.

But as thorough as it was it only touched on a subset of needs, and 
ultimately there needed to be a tool to work with that metadata for easy 
installation - so then Ken worked with the community to make DropTools:
http://droptools.sonsothunder.com/index.irev

That took things even further, but as nice as it was it really only 
reflects the state of componentry in LiveCode at a particular time in 
the past.

Today's Widgets take extensibility in LiveCode in a bold new direction, 
with a spec far more complete than any other could possibly be without 
engine enhancements.

Let's take a second look at Peter's description of their packager goals:

    - version management
    - dependency management
    - checksums
    - cryptographic signatures
    - etc. etc.

Even the best community efforts to date, the ECMI spec and DropTools, 
could only address the first two on that list.  For checksums and 
signatures to be meaningful they need enforcement beyond the reach of 
scripts - after all, if a script is responsible for managing those the 
script can be altered by malware to grant trust to untrusted packages.

So we had ECMI/DropTools, and now the core dev team is working on a far 
more complete packaging spec and toolkit.

We could choose to draft a third, but we risk this:
https://xkcd.com/927/

At the moment we know they're actively working on it, and that they 
intend to release in a time frame of "a few months".  And we also know 
that they need it perhaps more than anyone else.

So rather than draft a third spec which is likely to be obsolete within 
months and certain to be obsolete sooner or later even if the "a few 
months" gets stretched a bit, I'd rather let them handle it and just 
focus on my own stuff.

But that's just me.  If you can get support from other devs to use a 
third interim spec go for it.


> Moreover I could mirror the site here in EU (no LC server, LC
> server yes in US at on-rev), so that we have 'nearest places'
> for download.
>
> To take only the forum and the use-list: There are > 1000
> stacks and scripts that could go unchanged, only attached with
> indexing tags, into that collection.
>
> I don't think this would touch the packaging of the delayed
> Extension Store feature. To the contrary, we could have a
> category 'previews' where extension builder people could
> provide demos/"lite" versions and link to LC's Extension Store.

For the long term I believe the best solution is the one currently in 
development by the core team.

For the short term I believe the best solution *might* be to put 
RevOnline back in place as it's been for years.  But I say "might" 
because I don't know the reasoning behind it, and "why" is always 
critically important to learn when questioning a "what".

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com