On 6 March 2015 at 19:32, Andreas Säger <[email protected]> wrote: > Am 06.03.2015 um 16:06 schrieb Jaroslaw Staniek: >> On 5 March 2015 at 17:32, SOS <[email protected]> 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: [email protected] 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
