Re: [libreoffice-users] Re: Where is Base?

On 6 March 2015 at 19:32, Andreas Säger <villeroy@t-online.de> wrote:
> Am 06.03.2015 um 16:06 schrieb Jaroslaw Staniek:
> > On 5 March 2015 at 17:32, SOS <sos@pmg.be> wrote:
> > > Stefan ,
> > >
> > > Macro's can "live" in any document so also in a "Standalone form" , better
> > > is to place your macro's in the LO application, who makes is fast more easy
> > > to Update and distribute for several users as a extension.
> >
> > Just curious, per a good practice, why the macros wouldn't be stored
> > on the server as other db objects (data)?
> > Why in the networked era, user needs to update their clients? We're in
> > post-networked era even.
> >
> > Because Kexi does that by design. But here local file (reliable
> > sqlite3 that -based on reports- almost never crashes for users) is
> > handled in the same way as any server so there are no special cases.
> > Asking because of an intent to harmonize behaviours and approaches.
>
> Because we are talking about office macros. An office macro is stored in
> the user profle, in the install directory or in an office document.

Thanks for sharing the perspective. I'll explain the simple logic
that's a building block of data-oriented environments such as Kexi.

Macro in LO is an equivalent of an MS Access module, which is stored
in database, just like in Kexi.
It's also an equivalent of a stored procedure, which is stored in a
database, and in addition execution engine usually happens to be
bundled in the same product database and can be controlled using the
same channel as data, structure and triggers are controlled.

(Sorry if I am writing this under the eyes of seasoned (real) db users
but still I hope it will be useful to someone)

I don't need to mention that sharing authentication rules and
transmission channels with the database engine is beneficial for
security. Compare that to storing code in home directory, enabled for
free modification.

> What you have up and running on your server is a database. The office
> suite and the database are 2 completely separate things. The database
> accepts requests and returns requested record sets without knowing any
> of your queries, forms, reports and macros.

> It accepts the exact same
> requests from your web server returning the exact same record sets
> without knowing anyting about your web server, script language or the
> client's browser.

True, just like the database does not know that a NAME column's
semantics is "person's name".
It's the one or two upper layer(s) of your architecture that implement
the semantics.

Scripts/macros/forms/reports/query statements and everything else are
strings perfectly stored. Just like your bash scripts in a file
system. They are programs, stored as arrays of characters, without any
knowledge what's inside.

From that perspective, database is a storage medium, just like a file
system, with a different feature set.
For executing it you need an execution engine (javascript or python or
a clone of VB, etc.) and an execution context. Execution in an
environment itself calls a process call into being.

Ability of handling _programs_ on the server side is irrelevant to
ability of properly storing (textual, or binary) definition of
_macros_ and offering them to clients for retrieval, maybe versioning,
and protecting the access.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted