mod6: I suppose when we get a landing page on our website we should have prices in btc, automatically converted on page load to btc from current BTC/USD VWAP
ben_vulpes: mod6: from whence the price signal though
ben_vulpes: maybe some day, but for now hand-cranked quotes are working
mod6: well, we could easily have a cron job that curls down the vwap once a day from any number of sites (lots of these have apis to grab from), write that value out to a file, then the webservice will suck that value in and calculate.
mod6: or if that's not tasteful, could be another manner, whatever is suitable.
Vexual: also, if we need more than one, can we spec different floors? alf or someone might go in chucking elbows
mod6: sorry, plz elaborate on 'spec different floors'? not sure what you're referring to.
Vexual: ideally they'd be on different power supplies
mod6: ahh. hmm, i don't have a solid answer for that -- im not sure how everything is currently configured, or how it may be configured in the future. perhaps one of the other gentlemen are better to answer this.
Vexual: all in one rack was my best guess, with more to come
mod6: yeah, im positive everything is in one rack, but i'm not sure how the power sources are configured.
mod6: i'll bet that alf will post pics when he returns
ben_vulpes: there are a few ways to set it up, but what i do is use triggers to fire notifications on channels, the payloads of which are the pk for the table on which the insert operation was performed
ben_vulpes: this lets an entirely separate process (on an entirely separate box perhaps, even) listen for inserts, retrieve the row, perform some computation, and then insert into an outbox table for forwarding to irc or performing other side effects
ben_vulpes: you can even make an erlangy crash-only-semantics system out of this, where your logger process never has to do anything but eat from irc and shit into the db, and eat from the outbox and shit into irc while side-effect/response-generator processes can crash at will
ben_vulpes: i don't think logbot as implemented is quite erlang robust though, a listening process i don't think will know about lines logged during the listening processes downtime
ben_vulpes: now what you could do, if the extra tables don't bother you, is maintain another table the listening/responding process maintains to keep track of which lines it's seen and responded to (if necessary)
lobbes: Interesting. This is valuable info to chew on. I'm gonna digest what you said, map it out to myself confirm I get it, and will ask any q's abour what I'm fuzzy on
lobbes: I think I get the gist, though, and it follows with what I was gleaning from reading teh logs on the topic