Center App Store

[Ivan Denisov]

Then I organize my website as your purpose then my website will be disappear sooner or later. Is that your aim?

This comment should be discussed carefully! My aim is to implement some ideas about components distribution, to make it easier for developers to publish components.

New version of your site we can put in:
http://beta.zinnamturm.eu (or other subdomain: http://cloud.zinnamturm.eu, http://inflow.zinnamturm.eu)
And hold there for many years. It will be submission system for your main site with a search and all other stuff we will experiment on.

Then you can take components from there and put in your collection in front version (main domain) as you are doing now with BlackBox.
If any time you will have some ideas how to implement automation of taking updates from beta to your old version I will help to do this. If you want keep doing this process manually it is your choice.

For not having a problems with a low, we can rename project from BlackBox Components Store to Component Pascal Collection [beta] and remove prices.
Please take a look the title now: http://apps.blackboxframework.org/

All license notices and prices developers can put in the description field like "that is demo version, commercial version is available by the request".
Developers have to solve all the low and trade problems by them self until we don't now how to organize this process.
Chris found nice platform for trading Astrobe, maybe he can share experience.

ALSO. This "beta" site can run in Center server to keep your server secure from PHP.

What do you think about this? Submission system for CPC ?

[Josef Templ]

Further important questions to answer are:

1. distribute extensions in source form or binary (compiled)?
2. moderated (by a human) or unmoderated (fully automated) app store?
3. get extensions from within BlackBox (e.g. extended Repository functionality) or from outside (Web Browser).
4. resolve dependencies manually or automatically?

The state of the art, of course are the app stores from Google and Apple, but
the various Linux package managers can also be used to get an inspiration and are
closer to our needs, I guess.

- Josef

[DGDanforth]

Further important questions to answer are:

1. distribute extensions in source form or binary (compiled)?
2. moderated (by a human) or unmoderated (fully automated) app store?
3. get extensions from within BlackBox (e.g. extended Repository functionality) or from outside (Web Browser).
4. resolve dependencies manually or automatically?

The state of the art, of course are the app stores from Google and Apple, but
the various Linux package managers can also be used to get an inspiration and are
closer to our needs, I guess.

- Josef

Nomenclature:
I prefer the term "subsystem" to "extension". Can we agree on a general form?
-Doug

[Ivan Denisov]

Can somebody, please, clarify the meaning of the word "component" for BlackBox?
Is it a module or it can be some set of modules? Can sybsystem be a "component"?
https://en.wikipedia.org/wiki/Component ... ngineering

"Subsystem" is a separate folder. However many subystems can be in one folder... This makes some mess.
Can we call this sets of modules "components"?

[Ivan Denisov]

Some ideas.

1. distribute extensions in source form or binary (compiled)?

Distribution of binaries is hard today because of signature problem. Each developer should sign binary.
BlackBox has nice form of encoded distribution we can use. My experiments are showing, that sybsystems can be automatically packed by StdCoder from repositories and then automatically decoded after uploading to user PC.

2. moderated (by a human) or unmoderated (fully automated) app store?

Both. There should be three groups:
- components without moderation (just submitted), there can be downloaded from web-interface only,
- a set of components passed automatic compilation tests, there can be seen from BlackBox components manager,
- manually checked components which Center can recommend to use for some Use cases (also seen from BlackBox, but have special quality mark).

There should be very strict rule, that moderator can not change sources or the description. User data should be untouched. It is very strict rule for current Internet ethics.
He can send some recommendation for the developer to improve quality of component to Center can recommend to use his component.

3. get extensions from within BlackBox (e.g. extended Repository functionality) or from outside (Web Browser).

All components from web, checked components from the BlackBox components browser.

4. resolve dependencies manually or automatically?

Developer should indicate dependencies with versions of components. Like FreeImage >= 1.6.
Then automatic tests try to perform check. If it passes, the component will be seen in BlackBox components browser.
While installation all dependencies automatically checked according current state of user BlackBox. We can keep some small text-based database of installed components and there versions.

[Josef Templ]

Nomenclature:
I prefer the term "subsystem" to "extension". Can we agree on a general form?
-Doug

Doug, if I look at your CPC contributions I find multiple packages that share a common subsystem: Gft.
Therefore a subsystem cannot be used as a unit of extension or component or whatever we call it.
The term 'Subsystem' already has a fixed technical meaning in Blackbox. It is a directory that contains
sources, resources, docu, etc in a standardized form.

We can use the term 'Component' to refer to any kind of BlackBox extension, be it a single module,
a set of modules, a subsystem, a set of subsystems, a menu command, a dialog, a docu file, etc.
'Component' would be anything that logically belongs together (it provides something useful that did not exist before)
and that can be installed or deinstalled or enabled and disabled.
It would be the unit of BlackBox system extension.

There have been many discussions and attempts to define the term 'Component' in the past.
See for example http://c2.com/cgi/wiki?ComponentDefinition.
Most are too narrow for our needs. In order to arrive at a 'Component' definition that meets
practical requirements it must be based on some technical properties.
Being able to download, install, uninstall, enable, or disable something would be such a foundation.

- Josef

[Josef Templ]

4. resolve dependencies manually or automatically?

Developer should indicate dependencies with versions of components. Like FreeImage >= 1.6.
Then automatic tests try to perform check. If it passes, the component will be seen in BlackBox components browser.
While installation all dependencies automatically checked according current state of user BlackBox. We can keep some small text-based database of installed components and there versions.

Good point.
One more question to be answered would be:
Do we want to have versioned or unversioned extensions?

Versioned extensions are more complicated.
You will be surprised how complicated they are if you go into the details.
CPC is unversioned as far as I know. You get the current version only.
But this worked pretty well so far because of the source code distribution.
Most incompatibilities go away be always re-compiling against the current BlackBox installation.
Binary distributions are more vulnerable to compatibility problems.

- Josef

[DGDanforth]

Josef,
Good summary and discussion about components.
In like of that, I change my stance and will use "extension" for things that can be bought/obtained from the App store.

[Josef Templ]

In the Linux world, people speak about 'packages' and a tool that manages the installation/deinstallation of packages
is called a 'package manager', for example the Redhat Package Manager (rpm) or the Debian Package Manager (dpkg).
The term 'Package' has the advantage that it avoids the confusion about the definition of 'Component'.
It focuses around the distribution of a set of files together with some additional information about dependencies and
installation scripts.

In our context, the term 'app store' would actually be a bit misleading.
We are not installing applications or apps.

- Josef

[Ivan Denisov]

The idea of Douglas was also to provide ability to sell ready applications. My idea is to unite "Packages Collection/Store" with his "Applications Store" by a Compilation Wizard. Developer can publish a package with Build-List.odc file which Compilation Wizard is using for building of ready separate application in the user PC. That is how we can make App Store this and this Compilation Wizard will be our "killer app" at the same time.

OK good.
This is starting to sound like "Slim Binaries" advocated by Michael Franz
(see discussion https://lists.inf.ethz.ch/pipermail/obe ... 02665.html )

I think it is very close to this idea.