--- Log opened Thu Feb 02 00:00:10 2012
10:05 < conseo> mcallan: just what i have forgotton in my mail, the idea to query the wiki for forum base urls (harvest pointers) is pretty good imo
10:06 < conseo> defining that on each position page is what you meant right? or user's page? anyway, this fixes already most issues, regardless of using an event based trigger or polling
11:48 < mcallan> yes, position page
11:51 < mcallan> conseo: but i think the update of feed clients must trigger immediately, or users will be unhappy
11:52 < conseo> mcallan: we can use event based triggers, but if it polls discussion media (from both candidate voter) every time a difference is clicked, it will cause some load. nothing not being able to deal with so
11:52 < conseo> mcallan: i'll figure it out
11:53 < conseo> i still care about the diff-bridges layout, because i think it is the heart of votorola
11:53 < conseo> my 2nd design was flawed, but i'll try to mock sth. up till the weekend which fixes most issues
12:01 < mcallan> once a diff is back-linked to the archive and added to the feed, there should be no load on subsequent clicks, right?
13:02 < conseo> the link might be called from anywhere, we have to check the reffer id to see if it is already indexed, i think
13:02 < conseo> refer
13:03 < conseo> mcallan: it is manageable, i think easy configuration and integration is most important. we can manage the load later imo
13:34 < mcallan> conseo: i was simplifying too much, and forgetting that a single diff can be posted multiple times.  solution is perhaps not to trigger when it's already posted at least once
13:36 < conseo> the main problem with the refer imo, is that we cannot scan when we first find that refer id (url), because nobody might have clicked it yet, but it would be very relevant still (say a niche forum).
13:36 < mcallan> mostly a diff is posted only once.  if info in the request indicates otherwise (e.g. referrer url points to a new post), then you could trigger on that.  stuff like that should work ok
13:36 < conseo> so we have to manually scan in intervals (maybe the original ten mins)
13:36 < conseo> and also index a particular forum when the refer id (url) is not yet known
13:37 < conseo> since we use http to crawl, we can enable caching and won't cause too much load that way
13:38 < mcallan> i would not depend much on referrer url unless it indicates a new re-post of a diff url in the *same* archive
13:38 < mcallan> to be sure, i am only interested here in the problem of rapid update, and polling is no solution for *that*
13:39 < mcallan> (but this is all for later, no need to hammer out details today)
13:39 < conseo> for rapid update we need an event triggered on new posts and the only thing close to that is the refer id
13:41 < conseo> we have gone with the crawling approach, because otherwise we needed a dedicated client instance for each forum. for web postings this would still not be enough and it has had drawbacks
13:41 < conseo> esp. loss of history
13:42 < mcallan> i don't follow.  any request for a fresh diff triggers update attempt.  you saying you cannot do a cheap update, without crawling entire archive?
13:42 < conseo> i can crawl only the interval to the last known post
13:42 < conseo> mcallan: this won't help because you create the diff before you post it
13:43 < conseo> it has nothing to do with communicating it
13:43 < mcallan> you didn't read my reply to the list
13:44 < conseo> i did but i have had my problems, because it was so long. if you can tell me how you imagine this very specific trigger, then i can do it. but i don't see any, because posting to communication media is off-votorola
13:44 < conseo> but anyway, i will read it again. i was just asking for this specific issue to be clarified
13:45 < mcallan> this is not long: http://mail.zelea.com/list/votorola/2012-February/001293.html
13:46 < conseo> One solution might be to ensure that discovery attempts
13:46 < conseo> are cheap and failures recoverable, because often the next attempt
13:46 < conseo> (step 3) will succeed.
13:46 < mcallan> :-) unquote
13:47 < conseo> yeah, sorry, didn't meant to post it that way
13:47 < conseo> mean
13:47 < conseo> there can be any time interval between 1) and 3), it can easily be days
13:47 < conseo> polling will be faster in most cases
13:47 < conseo> (e.g. one hour polling)
13:48 < mcallan> poll for what, the message is only posted in 3
13:48 < mcallan> wait a sec...
13:49 < conseo> ok
13:51 < mcallan> right, it may be days before anybody looks at the diff and triggers update...
13:52 < conseo> but we can poll, if the forum hasn't been polled in the last hour for example and otherwise use your proposal (imo)
13:52 < conseo> i mean hybrid of both
13:52 < mcallan> ... and somebody might look at talk track *without* looking at diff, and be unhappy at seeing it out of date ...
13:53 < conseo> sorry it is even more difficult to express precisely in english than in german and even there i have profound difficulties :-)
13:53 < conseo> exactly
13:53 < mcallan> (no prob) ... except they could not *know* it was out of date...
13:53 < mcallan> so could not be unhappy!
13:53 < conseo> well, but the discussion entry might be what pulls them in. or they revisit and find no new post vs. one new post
13:54 < conseo> the difference might be important
13:54 < conseo> yes, they won't know, but we can even give them a near life view. i would even go with 10 mins polling for the start and optimize that to keep the impact minimal
13:54 < conseo> but that is just my 2 pence
13:55 < mcallan> yes, polling is fine, that was never the issue...
13:55 < mcallan> the issue is, when i follow a diff url i *must* see the post i came from within a few seconds, or i will be unhappy
13:56 < conseo> i am happy to be back soon. not that newton-iterations to solve f(x)=0 are boring, the opposite, but your xf mockups of the two new tracks caught my imagination again
13:56 < mcallan> (ok, looking forward to having you back)
13:56 < conseo> mcallan: ok, new spec then, i have to model that, because the xf client updates only every 10 mins, which is bad in this case
13:57 < conseo> we could do a single timer update after the first visit+30 secs or so
13:57 < conseo> (maybe less)
13:57 < conseo> or we could poll every 10s in the first minute
13:57 < conseo> so no prob
13:58 < mcallan> nah, that's not robust
13:58 < mcallan> why don't you like my soln?
13:58 < conseo> mcallan: but i still feel the diff-bridge needs to be polished as much as possible, because it is really awesome, people just don't seem to get it
13:58 < conseo> i got good feedback on my presentation for it
13:59 < conseo> but i have explained it before as a discourse growing from two people over structuring it in a tree up to bringing tools together with ovn
14:00 < conseo> it is really the core of what we try to achieve imo, if it fails we cannot apply all the other facilities. and even ed still has difficulties using it
14:00 < mcallan> that's a different issue, and we can't talk it about here.  u didn't answer my q
14:00 < conseo> sure
14:00 < mcallan> why don't you like my soln?
14:00 < conseo> for what?
14:00 < mcallan> http://mail.zelea.com/list/votorola/2012-February/001293.html
14:01 < conseo> quote mcallan: "One solution might be to ensure that discovery attempts
14:01 < conseo> are cheap and failures recoverable, because often the next attempt
14:01 < conseo> (step 3) will succeed."
14:02 < mcallan> right.  if the requested diff is fresh, then the bridge will trigger an update
14:02 < conseo> exactly, but we can't predict how long crawling takes even for a single post. it might be <10s in 90% cases, but it depends on the forums speed
14:02 < mcallan> 10s is ok
14:03 < conseo> but all this is minor stuff (which has to be done precisely in the specs ofc.), i will do that next week, i think
14:03 < conseo> mcallan: yes, but it does not really depend on us, we (i) have to play around a bit
14:04 < conseo> but imo this update (lifeness issue) is minor if people don't get the difference bridge
14:05 < mcallan> not one person in the world has ever complained about the bridge
14:06 < mcallan> you can code a parallel bridge, but then probably i have to take over the diff feed
14:07 < conseo> mcallan: i won't do that to your harm. i want to reach consent on a better diff-bridge design with you if possible
14:07 < conseo> what i mean to say, i don't want to work against your planning
14:08 < conseo> i can do the bridge after the feed, but i think it is worth some effort, because it is so important for new users to understand this concept
14:09 < conseo> do you worry about loss of focus?
14:11 < mcallan> i won't stop you from working on anything (it's free software), but i can't give you much support if it's not high priority for mini beta.  i keep saying it, and i think it's true: *nobody* has once complained about the bridge
14:12 < mcallan> it'll be a huge addition to add that to your plate, which already seems full
14:16 < mcallan> i wouldn't want to throw away the existing bridge, because i like it.  i prefer a vertical diff.  so we'd have two bridges, and we'd have to write code that makes it a user preference.  a lot of work
14:20 < mcallan> as i mentioned, there were two attractions for me in your mockup:
14:20 < mcallan> (1) possibility of showing dialogue between the two headshots
14:21 < mcallan> (2) the attendant need to go to single word diffs, which i saw as an advantage for small texts
14:22 < mcallan> but (a) i can't figure out how to do (1), and (b) photos are a problem.  people want to see photos, but won't upload their own.  they upload goofy pictures instead
14:23 < mcallan> and we can (2) with the existing vertical layout, if we want
14:24 < mcallan> so personally, there are no more attractions for me in the horizontal layout.  i'm not sold on putting effort into it, myself
14:25 < mcallan> conseo: sorry, because i shifted on this without making it clear
14:25 < conseo> sold LOL
14:25 < conseo> ok
14:26 < conseo> mcallan: the dialoge is xf and you have solved it already with the tracks (1)
14:26 < mcallan> ("sold" is just expression, meaning convinced)
14:26 < conseo> yes
14:27 < mcallan> nah, the tracks don't do what i wanted for *dialogue*...
14:27 < conseo> dialogue: you mean the feed?
14:27 < mcallan> sort of, but between the two headshots in your mockup
14:28 < mcallan> i gave up on it.  if you can figure it out, then i would rethink, but it's difficult
14:28 < conseo> that would be nice, i am still thinking about it. i thought you dropped it with the xf-tracks
14:29 < mcallan> yes, the failure of that led me to the tracks
14:29 < mcallan> but the tracks don't do the same thing
14:29 < mcallan> the value of the tracks is in being new design for Xf
14:30 < mcallan> http://mail.zelea.com/list/votorola/2012-February/001295.html
14:30 < conseo> ok, i see it similiarly
14:30 < conseo> yes
14:30 < mcallan> (i'm afraid your feed might be casualty, unless we make it into a scene)
14:31 < conseo> ok, haven't read that one yet i think
14:31 < conseo> hmm, :-(
14:32 < mcallan> ofc, talk-like tracks are diff feeds underneath, just a different superficial view
14:33 < mcallan> so you could add talk track to your overflowing plate
14:34 < mcallan> conseo: focus on school, man.  this stuff will still be there, when you are done
14:35 < conseo> mcallan: sure, but since i am ill i have difficulties to concentrate myself. doing so on something you care about is much easier
14:35 < conseo> (than maths)
14:36 < conseo> also we haven't talked a lot in the last few months
14:36 < mcallan> and it's thursday, and i forgot
14:37 < conseo> but i think we are pretty clear now. the feed(s) are going to be merged in the more generic track design, which might be similiar but horizontal or vertical
14:37 < conseo> is the vertical feed also a possibility on the bridge (for example)?
14:38 < mcallan> yes, but normally only top bar/track is shown on non-xf pages.  read the whole post, though
14:39 < conseo> we could have a difference scene, aligning a track vertically (similiar to the diff-feed) on each side of the bridge showing the posts of each besides them in my diff-layout
14:39 < conseo> ok
14:40 < conseo> have done so already
14:41 < conseo> do you know what i mean?
14:42 < conseo> the track could also show a bubble popup on click without directly opening the medium, giving something similar to the current feed entries, but on demand in your horizontal form
14:44 < mcallan> i was looking for something intuitive that a new user would say, "ah, these two are talking!"
14:44 < conseo> ok
14:44 < mcallan> i gave up on it, but maybe you can brainstorm it
14:45 < mcallan> if it's possible, then i would be interested again.  but it's hard
14:46 < conseo> i will try to do my little best
14:46 < conseo> and with that in mind, i'll turn to newton now :-)
14:47 < conseo> mcallan: is anything blocking you?
14:47 < mcallan> nah, i'm just upgrading wicket
14:48 < mcallan> get well c, and don't overwork
14:49 < conseo> i don't, i like this stuff :-P
14:49 < conseo> thanks for taking your time :-)
14:50 < conseo> i'll write to the list if i can come up with something feasable
14:52 < mcallan> (my pleasure) but do remember that 1) health and 2) school are priorities
14:52 < mcallan> this stuff'll be here when you finish exams
14:55 < conseo> i remember. but school is boring, i want to do something about the state we are in, not just get a job. luckily i can apply a bit of school knowledge to votorola
14:56 < conseo> what bothers me is that i like to play around with coding as well, but i don't have to time to do that. i'd love to do some kernel stuff to deepen my knowledge about how systems work
14:57 < conseo> but well, you can't have it all and votorola is an interesting piece of software
14:57 < conseo> mcallan: back to learning now, will ping you when finished with exams
14:57 < conseo> (next wednesday hopefully)
14:59 < mcallan> ok, good luck on exams
14:59 < mcallan> (and get well!)
15:01 < conseo> only a cold, nothing dramatic
15:01 < conseo> thx
15:01 < conseo> and you do well too :-D
15:01 < conseo> cu
15:01 < mcallan> cu :-)
--- Log closed Fri Feb 03 00:00:26 2012