As a longtime user and sometime documentarian, John, I'd have to vote for going ahead, with some clear statement that makes it clear that this is an initial attempt to provide a long-requested feature. I think that while your points are valid, the general concepts involved are mostly straightforward, and users looking for this feature will put up with the rough edges.
The precedent here is the db backend, which has been a part of the package for a while, but continues to be considered experimental. Even with all its flaws, it's been included. I think this feature is easier for end users to groom than the db that is not a db. I vote for adding it. David _____________________________________________ From: John Ralls <[email protected]> Sent: Wed Nov 13 20:55:36 PST 2013 To: Patrick <[email protected]> Cc: Derek Atkins <[email protected]>, "[email protected] Devel" <[email protected]> Subject: Re: Bug 336843 - Attach files to Transactions On Nov 13, 2013, at 5:09 PM, Patrick <[email protected]> wrote: > Indeed, a very relevant question. I had thought about storing the file > itself in the database as a binary blob, but had concerns the db would > grow too large and cause other stability issues. Also, that wouldn't > work well with the XML back-end. > > I'm not sure how to ensure file availability, given any other program > or user outside of GNUCash could alter the filesystem (and, for > instance, delete the file.) That sounds intractable to me, assuming a > file:// url is used. Granted, there's nothing to guarantee an > http/https url will be around at next retrieval either. There is no > URL validation code in the input phase of the "Associate Location" > function - it'll just fail on retrieval. Same problem, different > space. > > Fundamentally, they are just links. But, to Derek's point, how then to > educate the user-base so as not to cause resentment when someone's > relative removes the linked files and the user blames GnuCash. > > In the end, I gave up pondering this further as I wasn't getting > anywhere. Definitely non-trivial. The other application project I work on, Gramps [1], has a similar feature for linking "media" (image) files. It offers some tools for (re)configuring the root path on relative file names along with an option for storing either relative or absolute pathnames and a tool for switching from relative to absolute and back. It also offers an option to include "media" in a zipped backup bundle. The way to manage user expectations is documentation, which there isn't any yet for this new feature. Considering that I'm holding off string and feature freeze for this, is it *really* mature enough to add 6 weeks before release? Roger it's a widely-requested feature, roger that someone made a public announcement implying that it's going to be in the next release, roger the code is simple and straightforward. But it's not documented and we don't really know what users expect. Can we get that information and meet the bulk of those expectations in 6 weeks? Regards, John Ralls [1] http://www.gramps-project.org _____________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
