Re: GnuCash as server [WAS: Re: GnuCash page on GO site]
- From: Josh Sled <jsled-gnomeoffice asynchronous org>
- To: Linas Vepstas <linas linas org>
- Cc: Josh Sled <jsled-gnomeoffice asynchronous org>, Tim Wunder <tim thewunders org>, gnucash-devel gnucash org, Gnome Office <gnome-office-list gnome org>
- Subject: Re: GnuCash as server [WAS: Re: GnuCash page on GO site]
- Date: Thu, 26 Feb 2004 13:04:21 -0500
On Thu, Feb 26, 2004 at 11:55:22AM -0600, Linas Vepstas wrote:
| On Thu, Feb 26, 2004 at 12:13:49PM -0500, Josh Sled was heard to remark:
| >
| > To be clear:
| > * iCalendar [RFC2445]: not XML
| > * RDF Calendar: RDF [can be serialized as [RDF/]XML, or in other forms].
|
| Well, all that's left is to write a gnucash conduit to export
| scheduled transactions as ical/rdf, right? and then when I
| open evolution, they'll be there on the calander, right?
If exported, sure; this could be done pretty easily.
I like the server idea because evo can then do a 'GET
/scheduled?count=10[&format=iCal]' at it's leisure, w/o user intervention.
This is obviously work on both sides ...
To ramble-on a bit more...
The next question becomes, how does Evo allow action on those items?
I think, if the items have a link to ... say ... 'GET /scheduled/42',
which has a media-type of "application/gnucash-scheduled-transaction', evo
[or whatever] could use the system URL handler could spawn the appropriate
gnucash front-end on the URI when the link is traversed...
...jsled
--
http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo ${a} ${b}`
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]