--- Log opened Wed May 15 00:00:10 2013
11:20 < conseo> mcallan: yes, i think so too. the market is not neutral grounds, we need to connect people directly and do so ourselves as well. after all self-determination is not following the rules of the market unless you want to.
12:28 < conseo> mcallan: ping
21:07 < mcallan> conseo: pong
21:41 < conseo> mcallan: if we can agree upon a design for the new counting algorithm i could cover that in clojure, exporting it as jar with java api. if this is helpful for you and gives you time to work on the other pipe stuff
21:42 < conseo> i have written that in the mail as well
21:46 < conseo> you have complained about the dev-process being so slow, mine is now roughly 10 times faster without kidding, because i have an instant feedback loop to my product. it is like magic sometimes. i hack for a night and have a small elegant solution which would cost me 100s of lines and headaches in java. i would like to demonstrate it to you without insult, but rather to help votorola. it should not interfere except
21:46 < conseo>  where you would have to work upon anyway (demoing it in process)
21:48 < conseo> in other words, if i can help you with my new lovely environment, let me know.
22:26 < mcallan> i haven't caught up with mail yet... but i think both count engines need to support pipes...
22:28 < mcallan> is your own engine working yet?
22:40 < conseo> its still a playground, but i haven't figured out the details of the new counting concept yet.
22:40 < conseo> how pipes are counted
22:42 < conseo> if it is just counting them with zero and i can get vote events pushed by java api (wicket web-frontend), i am good to go, still it would make sense to explicitly pin down the current requirements beforehand
22:48 < mcallan> they are just zero i think.  the voting events are unimportant, i wouldn't worry about those...
22:51 < mcallan> hardest part is perhaps the uncast corrections, thought i'm not sure: http://zelea.com/project/votorola/_/javadoc/votorola/a/count/CountNodeW.html#uncastCarryCyclic(votorola.a.count.CountNodeW[])
22:52 < mcallan> which raises the question of how a different count engine (impl of CountNodeW etc) could be plugged in
22:56 < mcallan> agree on interfaces, i guess
23:10 < conseo> easiest is to define form of input data and expected form of output
23:10 < conseo> sql is fine for me
23:11 < conseo> we already assume votorola style counting, because the translation comes between p2p storage and count-engine independently
23:13 < conseo> mcallan: ok, i see you mean cycles
23:19 < mcallan> true, just define count engine as what populates the database *when* you call vocount.  or define it as an alternative to vocount.  either way, the impl. of CountNodeW is then not part of *any* count engine, though it might optionally be *used* by any engine, or not
23:21 < mcallan> my engine uses it, your's probably won't.  as long as the database design matches exactly, the engine that populates it should be transparent to all other code
23:21 < conseo> exactly
23:22 < mcallan> ok, that's simplest way to start, anyway
23:30 < conseo> yes, so i should just try to create the same content in the sql table? for me this is atm.: servicename  |  email   |   bar    |   candidateemail    | carrycount | dartsector | iscast | rank | rankindex | receivecount |     time      | xml
23:32 < conseo> or can we reduce that?
23:35 < conseo> read "break in separate processes"
23:36 < mcallan> not sure what you mean.  it seems a fully rationalized schema.  columns are mostly defined here: http://zelea.com/project/votorola/_/javadoc/votorola/a/count/CountNodeW.html
23:38 < mcallan> nothing to gain by breaking.  but think about it, and make a specific proposal.  it can be changed if necessary
23:46 < conseo> ok
--- Log closed Thu May 16 00:00:27 2013