[Grok-dev] an application installation script?

[Brandon Craig Rhodes]

Martijn Faassen <faassen at startifact.com> writes:

> We have two different scenarios:
> * development
> * deployment
>
> For deployment a pretty strong case can be made that in some cases
> you'd not want people to go to the web UI at all to install an
> application. Of course, this is mostly from a *nix perspective - on
> Windows for instance people might very well prefer to install an
> application by clicking on a UI.

I did not find that confusion about the "application instance" was
limited to Unix users; it was actually a Windows user who asked first!
Even under Windows, do you have to do things like the following?:

 - You download the Firefox installer, and it runs and places Firefox
   on your hard drive.  Then you start it up, and a GUI shows that you
   have a "blank slate" with no Firefox instances created yet.  So you
   create a Firefox instance, maybe named "myfirefox" or "ff", and
   then you have to select it from the list, and then up comes an
   actual browser window.

 - You download the Google Earth installer, and run it, and it places
   Google Earth on your hard drive.  You click on the icon, and up
   comes a small GUI showing you that you have no instances of Google
   Earth created yet.  You have to click on "Create Earth", then give
   it a name ("myearth" or "earth1" or whatever), and then have to
   select it from a list before it runs.

You will object, of course, that a Grok instance is more like a
database instance than like Firefox or Google Earth, which is quite
valid, so let me make the comparison more precisely.  Imagine:

 - You install Subversion.  You then run "svnadmin create" to build
   your repository.  You start up Subversion, and a GUI comes up that
   says you can't store files yet because you don't have a Subversion
   instance stored in your Subversion repository yet.  You are forced
   to create a "Subversion instance" inside your repository, give it a
   cute name, and only then can start storing files.

   Oh, and all your Subversion URLs wind up with an inexplicable and
   extraneous /mysvn/ in the middle because the instance is standing
   between you and your files.

 - Imagine that you install Postgres.  You run "dbcreate" to build
   your database cluster.  And then...

   Well, drat!

   There goes my example! :-)

   You *do* actually have to then start up the Postgres daemon, run
   "psql -l" and see that there are no actual databases created yet,
   and run "dbcreate" with a cute name like "brandon" or "testdb" or
   whatever, and only then do you have somewhere to actually place
   tables and data.

So the question to ask here is whether Grok, for the beginner, ought
to act more like Subversion, where once you have (a) its binaries
(which correspond to the Grok and Zope 3 eggs) and (b) a repository
(which corresponds to a Grok instance), then you can run the server
and see the result without an extra level of indirection; or whether
Grok ought to be more like Postgres.

You may well intend for Grok to be more like a database cluster than
like a Subversion repository; all I can answer is that the beginners
to whom I have shown Grok are more like Subversion admins than like
DBAs, and are confused about why their App code doesn't just get run
by Grok when they access the root.

> For development the case seems less strong.  We've heard Philipp
> report that this is confusing for beginners.  I hadn't noticed this
> in the Grok tutorial I gave and others don't seem to have noticed
> this either.

Why on earth would you develop more than one application at once?
Development requires shutting down the *entire dratted Zope 3 daemon*
and starting it back up, and then repeating this loop hundreds of
times a day.  The last thing one would want, I would think, would be
to have to wait for several applications' worth of code to be grokked
every time one ran "zopectl fg"!

And it's not like I can test and debug several applications at once
anyway.

Well, okay, maybe I could; I could open browser windows to the two
apps (":8080/myapp1" and ":8080/myapp2", say), and then two editors,
and with each "zopectl fg" I could hit "reload" on both browsers, and
then go edit both bits of source code to fix my next problem or add
the next button.  And, given the amount of time Grok requires to
start, I might actually save time this way, by spreading the app
startup time over two development sessions at once rather than one at
a time. :-)

But, is this really going to be a common case?

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon