[gnome-db] Re: Abiword report generator [was Re: Dynamic data queries]
- From: linas linas org (Linas Vepstas)
- To: msevior physics unimelb edu au
- Cc: Linas Vepstas <linas linas org>, Dru <andru treshna com>, gnome-db-list gnome org, Charles Goodwin <charlie xwt org>, Andrew Hill <dru treshna com>, gnucash-devel gnucash org, gnome-office-list gnome org, Tim Lord <timl treshna com>
- Subject: [gnome-db] Re: Abiword report generator [was Re: Dynamic data queries]
- Date: Tue, 9 Mar 2004 09:47:06 -0600
Hi Martin,
Well, I wouldn't have written the previous email if I'd read this one
first. You cover all the issues of nesting & etc. that I was concerned
about.
On Tue, Mar 09, 2004 at 09:28:55PM +1100, msevior physics unimelb edu au was heard to remark:
> OK we could do this securely if Abi was linked into your app's address
> space or if it was specfically invoked with the PID of the calling process
> or if activated as a bonobo component.
? what security exposure is there?
The traditional security exposure is tricking someone into running
malicious code. But I don't see how sending text/colors to/from abi
would be a security exposure.
(There is a subtle one that bank web sites suffer from, if they
use SSL for the web page, but don't use SSL for the gif's. The
interloper could replace the gif's by something else, tricking
the bank customer. But that scenario doesn't apply here.)
> Furthermore, there is no reason your changes to the document need to occur
> before the document is displayed on the screen. We could implement a
> listener in the AbiWord gtk main-loop and have the document respond to
> "events" and data generated from your app.
That's work. The only additional request might be to allow
the app to hide all or almost all of teh abi menus, toolbar, etc.
> The AbiWord document model, which we call the piecetable, has arbitary
> collections of named properties. We just invent a property called, say,
> "external-source". The value of the property of the "external-source" is
> some unique identifier which your app would use to specfiy what gets
> changed.
yep.
> The listener in the AbiWord main-loop responds to events from your app.
> You specify what unique-id you want changed and tell abi what the change
> is. It could be different text, it could be changed properties (boldness,
> font, colour etc). It might even be different stuctures. (Turn a 4 column
> table into a 10 column table).
yep.
> It could be anything we currently do via the GUI. The only difference is
> that it's remote app that does it.
Yep.
> It would work because we could map regions of matching "external-source"
> properties to locations within the document and apply our standard
> document manipulation techniques to that region.
yep.
> We could even handle discontinuous regions with identical external source
> ID's.
yep ... that would solve one of my scenarios.
> The listener performas the changes on the piecetable and the document will
> update it's onscreen representation.
Excellent. Thank you.
It sounds to me like "nice looking reports" are suddenly going to
no longer be an issue for a whole lotta people. Or at least, this
lobs the ball back into the other court.
If you will allow me to say one more thing that is probably
self-evident: if/when you do this, add 3 or 4 simple example
programs to the website. Having clear simple examples that
get to the point will really open the eyes of the world.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]