Finance::Quote questions...

[Paul Fenwick]

--Z9t8O/5YJLB6LEUl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

G'day Rob,

On Sat, Mar 17, 2001 at 05:28:39PM -0600, Rob Browning wrote:

> (Sorry it took so long for me to reply.  For some reason, mailcrpt and
>  gnus didn't believe there was an encrypted part to your message
>  (probably some MIME/mailcrypt/gnus interaction), and I kept thinking
>  I'd have a moment to track it down.  Instead I finally just decoded
>  it by hand :> I really should be using encryption/signing more
>  often...)

Okay, I'll just sign, and not encrypt from now on.  :)


> > If you want to be even more paranoid, then you can only load the
> > specific module that you're interested in at object creation time:
> >
> >	my $quoter =3D3D Finance::Quote->new("fidelity");
>=20
> Actually, what I ended up doing was what I mentioned before, just
> calling the backends directly, as you do in the test files.  i.e.:
>=20
>   $quoter->fidelity_direct("FSELX");
>=20
> etc.  That seemed like exactly what I wanted once I figured it out.
> Other than fallover's, is there any disadvantage to that?  (Ahh, I see
> you've already answered that somewhat below)...

I'm looking over finance-quote-helper.in now, and yes, there are
a couple of disadvantages.  Besides from:

> > Ah, I wouldn't avoid fetch if possible.  $q->fidelity_direct will
> > generate a Finance::Quote object on-the-fly with what it feels are
> > reasonable defaults, which may not be what you want.  Using
> > $q->fetch("fidelity_direct",@symbols) will give you the equivilent
> > information, but will respect whatever proxy, failover, timeout, and
> > other settings you've set on your quote object.

It also means that you need to modify f-q-helper if new modules
are added to Fianance::Quote, and the next version will have at
least two (and possibly three or four) new information sources which
various people have contributed.

F::Q is also moving towards making it as easy as possible for people
to write their own modules which can be plugged into F::Q, but
which are not necessarily part of the standard distro.  This makes
it easier for people to use third party, proprietary, or private
modules.  Again, users would need to modify f-q-helper to use
these new (non-standard) modules.  I've already had the authors
and users of some of the modules provided in newer versions of F::Q
ask if it's possible to use them from GnuCash.

My understanding is that the main concern is to ensure that users
get what they're expecting -- no failovers, and a predefined,
known module being called.  I think this is important, so I'd
suggest that perhaps we do something similar to the following:

	1.) F::Q modules can register (or more likely, are assigned)
	    a unique source-string which guarnatees that module (and only
	    that module) is called.  F::Q will verify that these
	    source-strings are unique.

	2.) F::Q provides function calls that return:
		(a) All available sources that can be called
		    (many of these will include failovers),

		(b) All available unique source-strings (as per (1)
		    above.

	3.) An extra setting is built into F::Q that requires that
	    all fetch calls ONLY use unique source-string methods.

In this way, it's possible to turn on a setting and be sure that
users will not hit failovers or use an ambiguous module.  It also
means that one can query F::Q to see what sources are available,
which is handy to present a user with a list of choices, or to
verify that certain sources are available.

This would be fairly easy to add to F::Q, would have advantages
outside of just F::Q and GnuCash, and should simplify f-q-helper
and provide an extra set of checks.

> Right, and that may mean that in gnucash we need to suggest that
> people prefer the yahoo method, but for the sake of data integrity, I
> don't want gnucash to fallover to yahoo if the user explicitly
> requested fidelity.  As far as I know, fidelity and yahoo might
> interpret FOO.X as different securities, and that wouldn't be OK :>

Most certainly.  ASX and Yahoo Australia treat indexes differently,
so there are real-world examples of why you'd want this.

> > Given sources don't tend to move around very much.  For example, the
> > Australian Stock Exchange is very unlikely to move from
> > Australia/Sydney time.  This could certainly be coded into the
> > modules.  I'll put this on the want-list as well.
>=20
> The problem is that I, at least, don't know where a given symbol
> lives.  I.e. what if the user can ask yahoo for "FOO.Pa" and get
> something off the paris stock exchange which (I presume) won't be in
> America/New_York time.  It seems to me that you have to know
> *per-symbol* on a given exchange what timezone the data's coming from.

Yes, that is a problem.  Yahoo and potentially some of the newer
modules which provide wide-access quotes can be coaxed into
providing information from widely different sources.  For
some sources we *CAN* be sure, for others it might require
some more jumping through hoops.  I'd rather not provide timezone
information than return TZ info that's potentially wrong.
The way things are at the moment (user specified TZ) sounds
safe.

Cheers,

	Paul

--=20
Paul Fenwick <pjf@cpan.org>         | "When I see an adult on a bicycle,
Senior Consultant                   |  I have a hope for the human race."
Obsidian Consulting Group           |      -- H.G. Wells

--Z9t8O/5YJLB6LEUl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6+SJHx5N6j7FHnlURAuTTAJ4yH1tKVIMzUMKVgaqu7LaxplTNZACeIOe0
9DkS/Gl0mNJsijLySbi/hPg=
=QP4T
-----END PGP SIGNATURE-----

--Z9t8O/5YJLB6LEUl--