[Grok-dev] Sprint proposal

[Paul Sephton]

On 9/25/2015 12:00 PM, grok-dev-request at zope.org wrote:
> Today's Topics:
>
>     1. Grok Sprint At Plone Converence? (Christopher Lozinski)
Just in answer to Chris Lozinski's ideas for a sprint:

Warning: Wall of Text Follows....

1) I have found that one of the worst things one can do is run 
bin/buildout without first pinning package versions.  Quite simply, 
newer packages are often incompatible with an existing project's install 
base.  As I already have quite a few apps in production, and may need to 
use grokproject in future to install new bases for these projects, I am 
not too enamored of the idea of introducing unnecessary change.

Perhaps we should think of making grokproject version specific, allowing 
for a stable base for production apps.  If we could specify a version 
tag to grokproject, then newer changes to the ecosystem could be done 
without fear of breaking legacy stuff.

2) If you don't already have a cert, then the first step is getting 
one.  Generate a private key using openssl, and make a certificate 
signing request (CSR), which is a file containing all of your site 
details and your public key.  The CSR must then be signed by a 
certification authority.  StartSSL provides web certs for free, and I 
heard recently that the free software foundation have also got 
themselves involved as a CA.

Once you have your cert and private key, you need to put those in a 
place where Apache can find them (usually /etc/apache/ssl) and configure 
apache to use the files.  You may also need the CA's certificates which 
can be freely downloaded.  Normally the permissions on the ssl cert/key 
files must be 0600 otherwise Apache ignores them.  There's plenty of 
Apache docs available on the web for configuring these.

3) Serving JSON from grok is as simple as defining a grok.JSON view.  
Similarly for grok.REST.  Perhaps I misunderstand the idea of tying this 
into ZODB?

The corporate marketplace  - at least the e-commerce marketplace - no 
longer needs programmers.  Anyone with some rudimentary skills can knock 
together a Wordpress site or configure a shopping cart like Zen Cart.

Unfortunate though this may be, the fact is that unless you are trying 
to build something really specific, web apps are a dime a dozen and 
freely available.  Want a CMS? don't hire a dev, just use a ready made 
app off the shelf.

We are no longer in the year 2005.  We are a decade on.

As so many of these generic apps are based on PHP, at the most your 
corporate client may need a PHP dev or a DBA to customise a few things 
around an existing app.

For the same reasons, it makes very little sense to be building 
alternate web frameworks these days.  There is little interest in web 
frameworks outside of the specific non-general needs already catered for 
by generic web apps.  For example as a server for a specialised phonegap 
based mobile app.

In such cases, smart money is likely to follow existing established 
trends; python=Django, java=Spring, PHP=Laravel.  MySql or perhaps 
PostgreSQL if relational otherwise one of the NoSQL variants.

Where would Grok fit into this picture?  Unless it brings something 
really appealing to the mix, it's choice of a caveman for a logo is 
probably appropriate.

So what can Grok offer that others cannot?  In my opinion, the fact that 
it is based upon a component architecture brings an unprecedented degree 
of plugability and extensibility.  The ZCA is it's greatest strength, 
but somehow even those in the know find themselves apologising for the 
ZCA and how hard it is to learn. Pyramid hides the ZCA as much as it 
possibly can.

The idea of using ZCML to configure components to be plugged into the 
framework was patently ridiculous.   What is needed to make sense of it 
all, is a way to discover and configure components via a simple UI.  In 
Zope-2, dropping in a new PAU was as simple as adding it to the tree at 
the appropriate location- that is why Zope-2 was so popular.  We need 
that ease and simplicity back, and it's very much an attainable goal.

Just as the development of pluggable components is popular for Zope-2 
and Plone, there is every reason to believe that this kind of 
extensibility would help to popularize Grok.

Pluggability and re-usability of software components need not be a chore.