Hello, I would like to share some remarks and ideas about the e-gold automation interface, because it isn't all roses as far as I am concerned. This is from the perspective of a computer scientist and programmer. The following sounds a tad negative I fear... of course, the fact that there /is/ an automation interface is great, but it just feels like it could have been so much better... I try to propose some improvements after each point. Please read the foregoing reasoning as explanation of the proposal, not as a way to fry e-gold automation! After all, it takes a problem to invent an improvement ;-) ZEROES: When no transaction records are found in a history query, the website responds with `No records found'. This is pleasant for humans, but harder on a tool, which now must distinguish between two cases of the first line. If the zero-case would have been treated consistently (reporting nothing), the results would have been easier to parse. When no networking errors occur, then an end user tool can still decide to produce such an expressive remark to the end user, but there too, it would be wiser to produce elaborate error messages upon failure and simply produce empty output otherwise. (That is common on Un*x command lines, actually, and it works great if you trust your system. Furthermore, it makes piping one command's output into another easy and useful.) A similar unnecessary complication is demonstrated by the case of login errors. If those occur, a tool does not want a webpage with a new form, but instead I would want something that a tool can process. Because this is all web based, an HTTP error code `401 Unauthorized' should have been generated, nothing more! Perhaps adding an option to the current interface could make this happen. +++ A solution would be to include an option `textonly=1' in the argument lists to the scripts, and trust on HTTP errors to give meta-information about the communication. +++ If catching HTTP errors is too hard, an option `feedbackline=1' could make it possible to send a first line with feedback (such as `okay' or `auth error') in a computer-friendly format (say, prefix it with a number as done in HTTP). DATES: I thought about regularly retrieving my history from your service, say in a crontab script, and discovered this would be a pain because the only way to query for new records would be to use dates. Dates are somewhat scary (are the start/end times inclusive or exclusive, so can I miss or double something if my query for end=13:00:00 is followed by a query for start=13:00:00? What is the time zone used? How far do clocks run out of sync? Did I actually make that previous query, or was there some downtime problem at either side?) Dates are also a bit unpleasant to handle because they are so long and wildly formatted. +++ A solution would be to include a query modifier `after=123456' to the history query, and produce any (possibly no) records after the record with that transaction number; after having processed all received records, the computer can store the `last-record-number-received' in a variable `last-record-number-processed' and thus be certain that it receives only (and all) new records during the next query. +++ In the above solution, if downtime during processing may be a danger, it would be good to record the `last-record-number-received' in a variable for `queried-up-to-here' and compare it with the `last-record-number-processed'; in case of differences, manual intervention or something smarter can be sought. Sounds rigid to me! PASSWORDS: To me, the query functionality is less secret than paying. To access the automation interface, I am forced to use my payment password. If I want to query history from a virtual host, I must also store my primary password there! It would be great to use some other password. I am uncertain if the secondary password used for SCI verifications is a good option, but it sure is needed on that virtual host if I let it verify SCI transactions. +++ A solution would be to accept either primary or secondary password for history and balance inquiries. A modifier `usepassword=2' would select the secondary password, and `usepassword=1', the default, would select the primary password. REGEXPS: Please allow for regular expressions in some of the fields. I would specifically enjoy this on notes and payment IDs, so I can retrieve, for example, anything new with note /^dns\.vanrein\.org/renew\ .*/ instead of needing to administer the domain names I can expect at that place (and being forced to trouble your server multiple times, once for each domain name to check upon). +++ A solution would be to make a toggle `useregexp=1' to interpret the given fields as regular expressions. When using a web interface to these tools, a simple checkbox toggle can directly influence the flag, which is nicer than having separate fields for regexp_paymentid and normal paymentid. (That sure is a matter of taste!) COMMAS & QUOTES: Oh my, yet another language going throught the learning phases of "let's use comma's" -- "use quotes/escapes when needed" -- "aj, we should escape the escapes". Mind you, I still have no idea how a comma-separated field is submitted when it contains both single and double quotes, as well as commas and spaces. So, I am also unable to build a good parser... And please note that you had a character that never occurred in notes and that is easily parsed in most languages, namely the newline! In general, there are so many ways of folding a structure into a notation, including XDR, XML, IDL and Perl/Java/... serialisation methods... why invent a new one without existing code support??? +++ A solution follows. HTTP: It is a riddle to me why HTTP(S) has to be used for this protocol. Oh well, there's plenty of portable (and ported!) tool support for it, that surely counts as a reason. But that also goes for CORBA and the Java RMI. +++ A solution would be to support at least one other, object serialised, approach next to the current solution, on another port of the servers. CORBA, XML and Java are all quite heavy-weight facilities and therefore not ideal choices. If it must be light-weight, builtin serialisation from Perl might be a good idea. Or XDR (eXternal Data Representation), part of the RPC (Remote Procedure Call) standard by Sun, which is also very efficient (its main application is a layer below NFS, the Network File System that Sun made). --- I'd like to stress once again that I am happy that an automation interface exists. My remarks above demonstrate that I dislike /how/ it was done, that's all. Hope this helps, Rick van Rein, #143766 --- You are currently subscribed to e-gold-tech as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED]
