Win32 Port Efforts (eKA$H fork)

[Derek Atkins]

Hi,

Quoting jarney1 at cox.net:

>> * You added an extra data field to the Account data type, "asset class",
>> along with appropriate reading/writing code in the xml backend and an
>> extra asset-class.scm scheme report. What do you intend to use this data
>> field for? Also, this additional data field probably makes the data
>> files GnuCash and your fork "eKA$H" mutually incompatible (because the
>> gnucash parser will choke on the unknown XML element)?
>
> The "asset class" field was intended for tracking securities for 
> balancing an investment portfolio.  When you do this, an "Asset 
> class" refers to a classification of securities.  The dominant wisdom 
> in investing is that you should balance risk across different asset 
> classifications (i.e. large cap, mid cap, small cap, bond).  The XML 
> document needs to track this and the corresponding report tells you 
> what percentage of holdings are in these categories.  From time to 
> time, you should balance your holdings so that the balance of each 
> category is maintained.  The good news is that so far, I don't think 
> more than 5 people are using this version, so if another solution to 
> tracking asset categories is found, switching over to it should not 
> be a problem.

I question whether this belongs in the Account or in the Commodity?
If it's defined in the Account, then a user could theoretically declare
that instance A of commodity 1 is Asset Class X but instance B of commodity
1 is Asset Class Y.  Is this something that would ever make sense?

>> Feel free to continue to do so - that's the wonders of open source.
>> However, the potential data file incompatibility due to the "asset
>> class" data field would really bug us. Do you think you can implement
>> this with sufficient forward- and backward compatibility?
>
> Given that not many people are using it yet, I would like to work out 
> a way to implement this functionality in the upstream if possible.  
> It need not be compatible with what I have.  Would it be a reasonable 
> comprimise to add some kind of "misc" field(s) in the XML format for 
> purposes similar to this?  In that way, we could achieve 
> compatibility and flexibility in one fell swoop.

Well, I would store it in the KVP, sort of how transaction notes
are stored in the KVP.  But as I said earlier I think this particular
data should live with the commodity, and unfortunately I dont think the
current data file actually stores the Commodity KVP Frame, so it would
be problematic to put it there right now without making changes to the
XML code.

>> Good to hear. We also don't know more about this except for what is
>> already written on the wiki page. Thank you for your feedback and good
>> luck with your own business model and software package.
>
> I may need the luck.  Currently, the "business model" consists of 
> hanging around street corners with CDs saying "hey buddy, wanna buy 
> some source?"

Hehe.  I certainly wish you luck on this model.  When it's been tried
in the past it hasn't actually worked out well.  But I still wish you
luck.  And honestly I'd love to add your programming skills to the
gnucash project, assuming you're willing to push your changes up to us.

Still, we cordially invite you to hang out here and get involved with us.

Thanks,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available