Re: [H-source-users] Introduction

[bill-auger]

On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> ready to use free software programs that can be used right now without
> requiring software development effort.

ok; but the proposal is to re-write the entire system from
scratch - that is a huge software development effort, regardless
of which tools are used - if that is to happen, we should make
sure that it is well-motivated, and that the effort actually
addresses some existing problem - it is not obvious that anyone
but you, wants to contribute data to h-node via git

no matter how sound or well-intention the arguments may be; they
amount to rhetoric, if no one will actually use the
newly-designed system


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> The use of Git could be a barrier to people that want to contribute

there is no barrier to entry now - the h-client already solved
that problem - this is a non-issue for h-node


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> * Simpler
> * Less maintain burden
> * More resilient to change

i would argue that none of those are true for h-node

> * Simpler
a PHP website is a relatively simple beast already - if there is
no database, then most PHP websites could be converted into a
static website, simply by rewriting the PHP with client-side JS
(if there is any PHP left at all) - in most cases, the only
essential job that the PHP does, is to access the database

> * Less maintain burden
it already requires basically zero maintenance - that is
evident by the fact that it has been un-maintained for several
years, yet it is still running

> * More resilient to change
a flat-file data schema would be arguably less resilient to
change - imagine trying to re-organize the schema - with a
typical fully-isolated back-end, that could be done with zero
changes to the front-end, as long as the API is preserved -
users should not need to now that any such internal changes were
made - this is the essence of data-hiding and OOP: isolating
the interface from implementation - this proposal conflates the
back-end/front-end, implementation/interface into one and the
same implementation - in effect, there is no interface - each
user contributes raw data manually, and directly into the
data-store - it is highly error-prone

in such a system, every person contributing data, would need to
have total knowledge of the acceptable data schema, before
adding each new record - if the data format changes, then any
data uploaded in the old format would be invalid - that is
unavoidable, of course; but it can be mitigated by validating
the client version - with the git proposal, the only client is
the generic git tool; and the incoming data formatting is
governed only by the brain of each user - ok, so add some
git hooks, with detailed explanations of why the data was
rejected - even so, that is not more resilient to change - it
only shifts the burden of adapting to changes, onto each user,
rather than upstream where it belongs

static websites are fine when there is very little data to
handle; but they become unwieldy and inefficient with a
complex schema data or a large data-set

likewise, manually-prepared data, submitted anonymously, is fine
when the data is not complex nor important (blogs, guestbooks,
forums, tweets, etc) - its a pretty bad idea otherwise


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> * Text only
> * No JavaScript
> * No web browser required
> * Readers and contributors can use free software programs of their
>   choice that meet their accessibility needs.
> * People who are using a FSDG operating system and have a GPU that does
>   not work without nonfree software (no graphical environment like Xorg
>   or Wayland) can still read and contribute.

h-client could also tick those boxes; and it would be a much
easier task to accomplish

the website could use some work in those areas - the search
feature requires javascript; though there is no essential reason
why it should


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> It does not look like h-client has received a commit since 2011.

none of this has been maintained for a long time - that is not a
justification to scrap it and re-implement everything from
scratch - the easiest path is almost always to build upon what
already exists, especially when nothing is broken


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> Is h-client written in Python 2?

yes, it will eventually need to be adapted for python3; which
is very easy in most cases - however, that is not urgent - it
is still fit for most distros


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> It looks like h-client has been packaged for only two FSDG operating
> systems.

distro packaging is generally not an upstream concern - but if
we wanted that to happen, the task at hand would be simply to
convince all FSDG distros to package it - it is somewhat
discouraging that they do not already - perhaps it could be
proposed as a FSDG suggestion or requirement - in any case, that
is more of a community-oriented task, not a development concern


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> A program like h-client could be created for preparing submissions to
> h-node if it was a Git repository.

it would not need to be created  - it already exists and is
fully usable with the current back-end - it would only need to
be adapted for a new back-end, if the new back-end is
incompatible

a CLI-only, or fully-automatic version could be written - thats
an excellent proposal


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> the database tables with user information could be dropped as they would
> no longer be required.

you may consider that some people like the idea of being
credited for their contributions - attribution is often an
incentive to contribute - attribution for previous contributions
should be preserved somehow


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> Guix does it's
> development using Git patches submitted to a mailing list.

that is a totally different sort of contribution, and is
always governed by authorized developers - the analogous
h-node/h-client software is already under VCS - this proposal is
to use git for a very different type of contribution: anonymous,
unauthorized data entry - i can not think of any example where
git is used for that purpose - thats not to say that it could
not be used for that purpose; but there is no bandwagon appeal
in this case - generally, anonymous, unfiltered, data
contributions result in a trash heap


On Sun, 18 Jul 2021 14:26:57 -0400 Bone wrote:
> How does Guix manage their contribution process to deal with spam?

code contributions are generally not targets for spam - one
very important factor is that code contributions are moderated -
no one submits code directly to the code-base without
authorization - i assume that guix has no spam problem because
all community submissions are via mailing lists; and mailing
lists generally have spam-filter tools in place

the canonical data-store should be guarded by authentication,
just as the code-base is - anonymous contributions, should come
in sone other channel, which would need to be monitored and
reviewed like "pull-requests" - that could be another git repo;
but it would be superfluous for that purpose - it may as well
patches sent to the existing mailing list - in that case, the
implementation of the back-end store would be irrelevant to
the user (as it should be), no changes to the existing code or
database would be necessary, and conventional spam-filter tools
could help with the spam - it would make no difference to
moderators - the only difference to anonymous contributors,
would be that it is slightly easier to use; because email
submissions also eliminate the requirement that non-technical
people must learn to use git

the real barrier to entry would remain though - that is: how do
users collect the relevant data? - if submitted by any other tool
than h-client, then each user would need to know which
command-line commands need to be to run, and then to copy-and
paste the outputs to an email manually - it would make more
sense to modify h-client to send anonymous results to the mailing
list