[EMAIL PROTECTED] (Linas Vepstas) writes:
>> Sure. Merging best of breed toys into goffice would be a help.
>> I suspect that overtime it may make sense to migrate towards some of
>> the goffice data types to avoid having to map in and out, but that
>
> I'm not sure what you refer to when you say
On Thu, 2004-02-26 at 05:13, Linas Vepstas wrote:
> My gut feel is that libgda offers the wrong abstractions.
> Although gnucash data can be (is) represented as SQL, that's
> the wrong place to work. There's a lot of pulling things together
> that must happen before the data is reportable. For
>> > > I can show
>> > > you how to construct documents that use libgda to pull in content
>> from whatever data source you want for programmable fields laid
>> out in tables.
>> >
>> > My gut feel is that libgda offers the wrong abstractions.
>> > Although gnucash data can be (is) represented as S
On Thu, Feb 26, 2004 at 02:06:34PM +, Charles Goodwin was heard to remark:
> On Thu, 2004-02-26 at 05:13, Linas Vepstas wrote:
> > My gut feel is that libgda offers the wrong abstractions.
> > Although gnucash data can be (is) represented as SQL, that's
> > the wrong place to work. There's a
On Fri, Feb 27, 2004 at 01:43:18AM +1100, [EMAIL PROTECTED] was heard to remark:
>
> I wasn't suggesting this code be in AbiWord. I was meant that we could
> invent some fields that could be filled *explicitly* by GNUcash. AbiWord
> would call out to the external GNUcash program via a plugin to ex
On Thu, Feb 26, 2004 at 08:59:39AM -0500, Derek Atkins was heard to remark:
>
> I don't think SQL is worse per se -- our implemention might be. I'm
> definitely keen on moving to an all-SQL database choice, either an
> embedded DB as the "file" replacement, or PG for larger sites. This
> is a hi
On Thu, Feb 26, 2004 at 01:00:39PM +, Calum Benson was heard to remark:
> On Thu, 2004-02-26 at 06:02, Linas Vepstas wrote:
>
> > In my particular need (I cannot speak in generality on this),
> > I want to have a list of items, on say, a neutral background,
> > and some of the items on the li
On Thu, Feb 26, 2004 at 11:31:40AM -0500, Josh Sled was heard to remark:
> Or the evolution people can do a GET against gnucashd to get upcoming
> scheduled transactions and invoice-due-dates info for the summary page.
If you can find an industry standard xml markup for representing
calander appoi
On Thu, Feb 26, 2004 at 10:52:31AM -0600, Linas Vepstas wrote:
| On Thu, Feb 26, 2004 at 11:31:40AM -0500, Josh Sled was heard to remark:
| > Or the evolution people can do a GET against gnucashd to get upcoming
| > scheduled transactions and invoice-due-dates info for the summary page.
[The cont
On 2/26/2004 12:01 PM, I believe that Josh Sled wrote:
On Thu, Feb 26, 2004 at 10:52:31AM -0600, Linas Vepstas wrote:
| On Thu, Feb 26, 2004 at 11:31:40AM -0500, Josh Sled was heard to remark:
| > Or the evolution people can do a GET against gnucashd to get upcoming
| > scheduled transactions and
On Thu, Feb 26, 2004 at 12:10:26PM -0500, Tim Wunder wrote:
| >Evolution already uses iCalendar, so it's all good. :)
| >
|
| And Mozilla and Korganizer and Outlook (I hear, anyway...)
| But it's not XML markup, is it?
So? XML is sometimes overrated. :)
To be clear:
* iCalendar [RFC2445]: not
On Thu, 2004-02-26 at 17:13, Josh Sled wrote:
> So? XML is sometimes overrated. :)
>
> To be clear:
> * iCalendar [RFC2445]: not XML
> * RDF Calendar: RDF [can be serialized as [RDF/]XML, or in other forms].
Just a slightl ramble; if you want XML then go with RDF Calender and
serialise it as XML
On Thu, Feb 26, 2004 at 05:43:52PM +, Charles Goodwin wrote:
| On Thu, 2004-02-26 at 17:13, Josh Sled wrote:
| Just a slightl ramble; if you want XML then go with RDF Calender and
| serialise it as XML.
+1 from me, even though it's all talk at this point. :)
| An RDF Calender <> iCalender
On Thu, Feb 26, 2004 at 05:06:06PM +, Calum Benson was heard to remark:
> On Thu, 2004-02-26 at 16:44, Linas Vepstas wrote:
> > On Thu, Feb 26, 2004 at 01:00
>
> > Well, no. The icon/progress indicator is much too small. You have to
> > focus your eyes to see it (literally). You can't just s
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, r
cb,
Thanks for this. I expect it should be useful.
John R
--Original Message-
From: cb <[EMAIL PROTECTED]>
Sent: Tuesday 10 February 2004 10:40 pm
To: Steve Dunham <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc:
Subject: Re: [Libofx-devel] Re: python script for OFX Statem
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
On Thu, 2004-02-26 at 05:59, Derek Atkins wrote:
> [EMAIL PROTECTED] (Linas Vepstas) writes:
> > I'm not sure what you refer to when you say "data types".
> > If you mean using things like gconf, then yes, we should do that.
> > Our current way of dealing with user defaults & etc. is homebrew
> >
[EMAIL PROTECTED] (Linas Vepstas) writes:
> yes, I think I have a whiz-bang automagic stunt that will do
> this, by using (don't tell anyone) dwi. I think it will make
> a lot of the exensibility problems go away. (don't be
> mislead by the dwi web page, I would *not* use dwi for the gui,
> only
> Personally I consider a move to an embedded-SQL engine higher priority
> than book closing (although not necessarily as high as cap-gains).
> Just FYI...
Can someone clarify all of this SQL backend talk? From the
standpoint of a home user, I'm perfectly happy with my common file
backen
> 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 ...
Hi all. I'm going to play curmudgeon again and say that,
while this is all well and good, I don't use evo and I
On Thu, Feb 26, 2004 at 02:58:11PM -0500, Clayton Carter wrote:
| Hi all. I'm going to play curmudgeon again and say that,
| while this is all well and good, I don't use evo and I have no plans
| to. In fact, I don't want my GC SXs showing up in my email client at
| all.
Well, it depend
> | PS - as for the question of how to make evo act on a SX, what's wrong
> | w/ 'PUT /scheduled?SXid=0?action=enter' ?
>
> PUT is already the verb in there. If you're going to have the "action"
> part, then "PUT" just becomes "DO", which isn't really useful.
Right, OK, so PUT is
Clayton Carter schrieb:
>
> > Personally I consider a move to an embedded-SQL engine higher priority
> > than book closing (although not necessarily as high as cap-gains).
> > Just FYI...
>
> Can someone clarify all of this SQL backend talk? From the
> standpoint of a home user, I'm perf
On Thu, 2004-02-26 at 19:58, Clayton Carter wrote:
> > 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 ...
>
> Hi all. I'm going to play curmudgeon again and say tha
On Thu, Feb 26, 2004 at 02:41:13PM -0500, Clayton Carter was heard to remark:
> PS - As a home user, I'd prefer see book closing sooner to later.
Yes, I'm trying to clear my plate and get around to finishing this.
Its mostly there; I suspect I need to do more testing & debugging,
and review the c
On Thu, Feb 26, 2004 at 01:03:48AM -0500, Derek Atkins wrote:
| At this point all the data has been moved, and accounts have been
| created.. So we're just waiting on DNS to get moved. Once that's
| changed we should be up and running again.
I'm having an issue tagging the tree:
[EMAIL PROTECT
On Thu, Feb 26, 2004 at 01:04:21PM -0500, Josh Sled was heard to remark:
> | >
> | > * 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 ic
> On Thu, Feb 26, 2004 at 11:31:40AM -0500, Josh Sled was heard to remark:
> > Or the evolution people can do a GET against gnucashd to get upcoming
> > scheduled transactions and invoice-due-dates info for the summary page.
>
> If you can find an industry standard xml markup for representing
> ca
29 matches
Mail list logo
