Abiword report generator [was Re: Dynamic data queries]

Linas Vepstas linas at linas.org
Tue Mar 9 09:47:06 CST 2004


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 at 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 at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933


More information about the gnucash-devel mailing list