13:00:29 <gmcharlt> #startmeeting
13:00:29 <pinesol_green> Meeting started Wed Feb  6 13:00:29 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:29 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:45 <gmcharlt> #info Agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:future_of_staff_client&#agenda
13:00:57 <gmcharlt> #topic quick round of intros
13:01:03 * gmcharlt = Galen Charlton, Equinox Software
13:01:08 <gmcharlt> er,
13:01:15 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox Software
13:01:21 <tsbere> #info tsbere = Thomas Berezansky, MVLC
13:01:25 <bshum> #info bshum = Ben Shum, Bibliomation
13:01:27 <berick> #info berick Bill Erickson, Equinox Software
13:01:27 <csharp> #info csharp = Chris Sharp, GPLS
13:01:31 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
13:01:33 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
13:01:34 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox Software
13:01:35 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
13:01:35 <DPearl> #info DPearl = Dan Pearl, C/W MARS
13:01:36 <jamesrf> #info jamesrf = James Fournie, BC Libraries Coop
13:01:38 <ktomita> #info ktomita = Kyle Tomita, Catalyst IT Services
13:01:42 <krvmga> #info krvmga = Jim Keenan C/W MARS
13:01:45 <Rogan_> #info Rogan_ = Rogan Hamby, SCLENDS
13:01:56 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
13:01:59 <davidboyle> #info davidboyle - David Boyle, Catalyst IT Services
13:02:04 <dbwells> #info dbwells = Dan Wells, Calvin College
13:02:17 <ColinC> #info Colin Campbell, PTFS-Europe Ltd
13:02:24 <alexlazar> #info alexlazar = Aleksey Lazar PALS MN
13:03:13 <eeevil> #info eeevil = Mike Rylander / ESI (slow, phone, driving)
13:03:19 <tspindler> #info Tim Spindler, C/W MARS
13:03:23 <gmcharlt> ok, folks can continue to introduce themselves, but let's get started
13:03:28 <berick> eeevil: eyes on the road! ;)
13:03:31 <gmcharlt> #topic Do we still need a staff client?
13:03:39 <denials> #info denials = Dan Scott / Laurentian
13:03:40 <gmcharlt> to set the stage, this special meeting came out of the previous dev meeting
13:03:50 <phasefx> #info phasefx = Jason Etheridge / ESI
13:03:57 <gmcharlt> in particular, the discussion surronding bug 1086458
13:03:57 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.3 "Staff client memory leaks in 2.3 and later" (affected: 4, heat: 34) [High,Triaged] https://launchpad.net/bugs/1086458
13:04:06 <bradl> #info bradl = Brad LaJeunesse, Equinox
13:04:11 <shopkins> #shopkins = sue Hopkins C/W MARS
13:04:19 <gmcharlt> and while phasefx and I and others have been making some progress tackling the specific memory leaks
13:04:36 <gmcharlt> I thought it a good idea for us to step back and think about the future of the staff client
13:04:46 <gmcharlt> the agenda lists various related proposals
13:05:25 <gmcharlt> so I'm first going to list them all so that we can decide which ones we want to focus on
13:05:38 <gmcharlt> so the proposals so far are
13:05:49 <gmcharlt> #info go (almost) entirely web-based
13:05:58 <gmcharlt> #info have a minimal staff client for things like printing
13:06:11 <gmcharlt> #info keep the staff client, but move as much as possible into chrome
13:06:17 <gmcharlt> #info remove Dojo from the staff client
13:06:22 <gmcharlt> #info implement websockets
13:06:39 <gmcharlt> #info perform a third-party performance analsysis
13:06:56 <gmcharlt> as you can see, some of these proposals are mutually exclusive
13:06:59 <gmcharlt> some are not
13:07:05 <tsbere> I disagree with the first two
13:07:10 <bradl> originally, back when EG was just on the whiteboard, the basic idea was to have a staff client that could handle network connectivity issues (even automagically go to standalone mode), but it obviously never got there.
13:07:51 <jamesrf> is it fair to say that the two main factors that make a staff client are offline mode and receipt printing?
13:08:05 <phasefx> there was also a librarian prejudice against web apps.  I think it may be a split opinion these days
13:08:34 <jasonb> Jason Boyer from Indiana - sorry I skipped an intro. I wanted to ask though, is there a specific reason that real, native clients aren't a viable option?
13:08:39 <tsbere> offline mode, receipt printing, local data storage concerns, and RFID integration are my thoughts for why we should be sticking with a staff client instead of web app
13:08:46 <berick> offline mode could be implemented today in a pure web app (offline/manifest)
13:09:15 <gmcharlt> in principle, a staff client can do some things much faster than any web app can ... but does anybody actually disagree with the statement that most of the staff client isn't actually very quick to respond?
13:09:17 <berick> we also get about 8MB of local/session storage in modern browsers (not sure if that's enough, but..)
13:09:31 <Dyrcona> jasonb: Portability is one major reason that native apps are not a consideration.
13:09:49 <gmcharlt> another con of staff clients is the fact that you have to deploy them and manage upgrades ... although of course that's gotten a lot easier with tsbere's work on client auto-update
13:10:05 <paxed> the staff client feels very sluggish to me, at least when looking at the dojo tables and such
13:10:12 <bradl> gmcharlt: does the Koha world have any regrets about being web-based only?
13:10:12 <tsbere> One major concern I have about a pure web app is browsers. Both keeping up with them and the fact that people change them. Printing in a pure web app is pretty much impossible to do without prompts now as well.
13:10:16 <alexlazar> almost entirely web-based client would be OS-agnostic, possibly allow libraries to run cheaper hardware (Chrome OS) and would not require local system admin access
13:10:43 <tspindler> for those who are not aware, c/wmars is experiencing some extreme problems with slowness
13:10:45 <gmcharlt> bradl: not really, except for label printing; offline circulation is managed via a couple options -- a standalone php app or a Firefox extension
13:11:02 <phasefx> one option for web-based is to not be browser agnostic, which defeats some of the point
13:11:17 <csharp> label printing in EG is not awesome either
13:11:41 <gmcharlt> phasefx: and that's certainly true in Koha -- the general notion is that the OPAC should run everywhere, but the staff web interface has always favored Firefox and more recently Chrome over IE
13:11:43 <Rogan_> chsarp is absolutely right about that, an ongoing complaint almost 4 years in for us
13:12:12 <bradl> I don't think the current state of the staff client makes anyone jump for joy :)
13:12:19 <dbwells> I think realistically, if we go web only, we will need to target a single browser.  We just don't have enough resources.
13:12:48 <gmcharlt> dbwells: I think targeting FF and Chrome would be reasonable, based on Koha's experience
13:12:59 <jamesrf> another benefit of web-only is that it could work on tablets
13:13:01 <denials> dbwells++
13:13:04 <Rogan_> nope.  Personally, I'm interested in a web based staff client but my mind is far from made up.
13:13:08 <gmcharlt> targetting IE as well depencds on somebody championing it
13:13:14 <alexlazar> dbwells: unless targeting more than one browser is free, becasue they support the same HTML5 and other standards
13:13:20 <bradl> dbwells++
13:13:21 <Rogan_> dbwells++
13:13:38 <paxed> from the i18n viewpoint, going web-only would make translations a bit easier, no need to reinstall the staff client to every workstation when the translation strings change.
13:13:39 <denials> "the same HTML5" and "standards" - hahaha :)
13:13:41 <gmcharlt> and of course, one thing to keep in mind is that a bunch of staff client interfaces *already* work in web browsers sans XUL
13:14:06 <jamesrf> i think if things were to go web-only targeting firefox makes a lot of sense in terms of transition
13:14:17 <phasefx> those are also some of the most clunky, perhaps because of our ancient dojo
13:14:28 <tsbere> I think if it does go web only there will be mutiny when people have to answer printer prompts all the time in circ ;)
13:14:30 <gmcharlt> OK, I'm going to give another couple minutes for this topic (I'm planning to run through them all pretty quickly, then leave time at the end for more in-depth discussions)
13:14:35 <wolf29> How do you handle offline data?
13:14:49 <ktomita> phasefx++
13:15:02 <denials> jamesrf: targeting an open-source browser in particular (firefox or chromium)
13:15:04 <jasonb> tsbere: losing all of the receipt context functoinality will also hurt.
13:15:24 <denials> wolf29: HTML(5) offers several different local storage possibilities, depending on the browser
13:15:39 <Dyrcona> denials beat me to it.
13:15:40 <csharp> but if we went with FF, couldn't receipt printing, etc. be done via addons?
13:15:43 <berick> wolf29: and offline application execution
13:15:52 <jamesrf> so it seems like not a lot of support for going the xul/chrome route?
13:15:55 <tsbere> if we are going to start using addons, why are we moving away from xul?
13:16:02 <tsbere> Note that web only we also lose top level menus and toolbars
13:16:03 <gmcharlt> jamesrf: we haven't discussed it
13:16:19 <wolf29> thanks.  just wanted to get it in the record..
13:16:32 <gmcharlt> #topic Move much as possible to chrome
13:16:40 <denials> tsbere: it could be a question of "a little bit of xul or NaCl" versus "scads"
13:16:51 <gmcharlt> I listed a cuople pros and cons in the agenda
13:17:16 <denials> where "chrome" means "local XUL client", not "Chrome the browser"
13:17:25 <denials> in case anyone is confused :)
13:17:28 <tsbere> I think moving things away from remote xul would help
13:17:45 <gmcharlt> biggest pro I see is signficantly improving responsiveness for loading UI elements and reducing how much we have to think about certain times of caching
13:17:55 <tsbere> A *lot* of requests for otherwise identical files happen right now in the system due to query strings being used to pass arguments. Moving those files local will reduce network traffic.
13:18:25 <gmcharlt> biggest con I see is that dropping remote XUL is going to increase the compiile/build/test cycle for staff client development
13:18:36 <denials> in general, the less that we stray from the mainstream (see tsbere's tremendous effort to keep remote xul working) the better we can focus on value-add dev, IMO
13:18:44 <phasefx> removing query strings in and of itself could also help with the staff client performance re: caching
13:18:48 <berick> denials++ exactly
13:19:06 <gmcharlt> another pro I see:  moving away from remote XUL, while not a completely mechanical thing, does lend itself to a bunch of devs working on it in parallel
13:19:08 <wolf29> tsbere++ libraries with weak network bandwidth will benefit
13:19:35 <berick> denials comment (re mainstream) is a great reason to avoid xul entirely, imo
13:19:48 <alexlazar> berick ++
13:19:48 <tsbere> moving away from remote xul also lets us make a less server dependent staff client
13:19:50 <senator> berick++
13:20:27 <phasefx> is anyone doing fancy tricks with remote xul and ip-based redirection for customization?
13:20:30 <tsbere> I don't see ditching xul as a good idea unless we are ditching the xulrunner staff client 100% and replacing it with an entirely different one
13:21:07 <tsbere> And while some people would like to see us ditch xulrunner in favor of other staff client platforms I don't see that happening anytime soon
13:21:22 <tsbere> If we are using xulrunner we should be using xul, basically
13:21:46 <gmcharlt> yeah, I see a balancing act
13:22:04 <gmcharlt> XULrunner is not a priority for Mozilla, but we have a lot invested in it
13:22:09 <jeff> there will be transition (of an undefined time / form), and moving the xulrunner staff client away from remote xul to local xul could be part of that.
13:22:32 <jeff> it would likely breath more life into / revive the xulrunner based staff client.
13:22:34 <gmcharlt> and sticking with it is potentially a lower hurdle for us in the medium term than adopting another platform
13:22:38 <bradl> gmcharlt: also balance that with the amount of time you and phasefx have spent plugging memory leak after memory leak
13:23:00 <alexlazar> we're going to have the staff client for a while regardless
13:23:03 <tsbere> most of the memory leaks I have seen being plugged can be blamed on coding styles, I think
13:23:09 <tsbere> not xulrunner or xul
13:23:18 <gmcharlt> bradl: yes, we've discovered that we're very much at the mercy of XULRunner's garbage collector ... and not because of Dojo, by the way
13:23:19 <tsbere> javascript closures are problematic, in particular
13:23:29 <alexlazar> plugging memory leaks is a worthwhile effort thank you
13:23:34 <berick> indeed, memory leaks can happen anywhere
13:24:01 <berick> and by anywhere, I mean IE, of coure
13:24:08 <bradl> berick++
13:24:11 <gmcharlt> berick++
13:24:15 <Rogan_> berick++
13:24:26 <jeff> and those interested in experiments such as implementing more staff features in web interfaces would gain the immediate benefits they seek from that (such as, say... support on platforms where xulrunner does not run), and said experiments would result in more data / insight as we further evaluate the status of the staff client / staff interfaces.
13:24:43 <csharp> berick++
13:25:27 <denials> jeff++
13:25:27 <gmcharlt> ok, moving on
13:25:30 <gmcharlt> #topic Removal of Dojo from staff client (proposal by Thomas Berezansky)
13:25:48 <edoceo> I'm in favour of a web-based staff-client; I presume less memory leaks and more likely to run on my Rasberry Pi - but it's years away
13:26:36 <krvmga> is dojo the for-certain culprit in poor performance in circ and patron edit screens?
13:26:43 <tsbere> My main arguments for removal of dojo (and not replacing it with another javascript framework) is the fact that these frameworks aren't designed with xul in mind, they are designed with html in mind. This includes how browsers treat web pages security-wise, which is very different from how xul is treated.
13:26:53 <gmcharlt> krvmga: nope, the leak profiler doesn't bear that out
13:27:26 <tsbere> Other arguments are the fact that almost every interface I have trouble with, and most of the ones I hear people complain heavily about, are dojo-based interfaces
13:27:39 <tsbere> and the fact that they just don't look right alongside the xul ones
13:27:51 <Dyrcona> I would say the question of removing Dojo is dependent on the decision to keep the xulrunner client or to go with a web client.
13:28:26 <Dyrcona> I think the web sockets question is orthogonal to both.
13:28:47 <gmcharlt> agreed; and I think the JavaScript framework is *also* orthogonal
13:28:49 <berick> Dyrcona: agreed on both pointt
13:29:25 <berick> i can understand how in a pure-xul environment, dojo (etc) makes less sense
13:29:50 <tsbere> The only arguments for dojo I have seen are "it lets us quickly make interfaces" but it isn't that hard to build on top of xul for most of those same uses
13:30:13 <Dyrcona> I think we ought to make a decision concerning xulrunner vs. web, then.
13:30:30 <csharp> so what happens if Mozilla stops developing/supporting xul?
13:30:37 <csharp> xulrunner, even
13:30:39 <acoomes> Dyrcona++
13:30:52 <berick> csharp: i think that's a valid concern
13:30:55 <denials> csharp: like they have abandoned xul on mobile, fer instance?
13:30:55 <gmcharlt> csharp: that's one of the not-so-invsible elephants in the room
13:30:59 <csharp> yes
13:31:00 <tsbere> csharp: Given that xulrunner is supposedly the base of firefox I imagine mozilla goes away entirely?
13:31:44 <csharp> but the xulrunner-not-as-a-component-of-firefox project is... tenuous (at least to me)
13:31:44 <denials> Or, they pivot on their mobile efforts for firefox.next, dropping xul. who knows?
13:31:47 <jeff> unless mozilla focuses their considerably-larger-than-Evergreen development resources toward changing/replacing xulrunner in a way / with something that is no longer suitable for Evergreen's use.
13:31:53 <gmcharlt> tsbere: I think that's not so likely as Mozilla deciding that they only care about XUL for their own projects and Firefox extensions
13:32:33 <wolf29> gmcharlt++
13:32:37 <jeff> gmcharlt: (such as changes to remote xul support)
13:32:44 <gmcharlt> jeff: indeed
13:32:52 <denials> In any case, rewriting all of the Dojo UIs we currently rely on in the staff client is not a trivial effort
13:33:11 <tsbere> but deciding to stop making new ones would help on that front
13:33:25 <ktomita> denials++
13:33:28 <alexlazar> tsbere++
13:33:43 <acoomes> tsbere++
13:33:44 <eeevil> that's a tough choice, too
13:33:51 <jeff> tsbere: you mentioned a desire to re-create some of the "let us quickly make interfaces" bits in local xul?
13:34:25 <tsbere> Most of the interfaces we can "quickly create" are simple config interfaces. Those should be trivial to make compatible with a fully xul interface.
13:34:26 <jeff> tsbere: sans a framework, building a framework ourselves, i take it?
13:34:52 <tsbere> The question becomes what other things are we thinking dojo lets us make?
13:35:20 <denials> It's currently used in the autosuggest UI in the TPAC.
13:35:42 * berick doesn't foresee anything trivial coming out of this discussion, regardless of the outcome
13:35:43 <tsbere> I am not looking to remove dojo from Evergreen 100%. Just from the staff client itself. The catalog can keep using it for autosuggest, IMO.
13:36:29 <csharp> I guess I'm not convinced that xulrunner is a safe bet for the future
13:36:34 <jeff> (feel free to indicate that this is not a question relevant to the current topic) Assuming dojo in the staff client stays, what efforts are required to take advantage of some of the (GSoC?) work done to bring us "more current" with recent Dojo releases?
13:36:47 <csharp> (says one who manages "we can no longer print" tickets after upgrades)
13:36:59 <bradl> csharp: I agree with you, FWIW
13:37:01 <tsbere> jeff: Re-write most to all of our dojo modules, I think.
13:37:16 <denials> So then we just need to pull the fieldmapper-parsing logic from openils.fieldmapper into a non-Dojo library and rely on that directly to generate XUL bits & control perms and such?
13:37:20 <tsbere> Which is another argument against dojo for me. If we have to re-write a lot of stuff, in whole or in part, why not just stop using the framework?
13:37:33 <jeff> xulrunner losing support for text-only printer drivers on windows was a pain for everyone, and not much of a pain for mozilla, thus another bug/change where xulrunner's focus left us behind.
13:37:37 <tsbere> I came up with a non-dojo fieldmapper already, for the record.
13:37:38 <csharp> at least dojo is an active project with its own momentum, for instance
13:38:08 <denials> tsbere: oh? might have been good to link to that in the meeting notes
13:38:16 <eeevil> rewrite is perhaps stronger than warranted
13:39:05 <tsbere> eeevil: The entire loading mechanism for dojo has changed significantly, just to start.
13:39:08 <denials> dojo 1.7 introduced a different loading mechanism, but I'm with eeevil
13:39:33 <jeff> csharp: web based rather than xulrunner has been identified as having challenges with: 1) offline (probably do-able now with modern browsers), 2) printing (i would like to investigate a native print client that knows how to print well, and only print well), but I'm also a bit worried about the cataloging interfaces.
13:39:36 <eeevil> but not the logic
13:39:53 <eeevil> just the wrapper
13:39:55 <jeff> csharp: implementing circ staff functions would be where i think of starting web-based experimentation.
13:40:05 <berick> jeff: what about the cataloging interfaces?
13:40:11 <berick> anything in particular?
13:40:22 <denials> that's a start, but seeing something complete and concrete beyond vague assertions that it's not suited for XUL would be better
13:40:55 <jeff> berick: sorry, i was doing a poor job of saying "implementing the marc editing functions in a web interface seems daunting to me at this point in time"
13:41:06 <jamesrf> eh just replace the cataloging interface with an XML editor
13:41:09 <jeff> berick: but not impossible, and likely with benefit if done well, etc. :-)
13:41:13 <denials> jeff: aww, you don't like openils.marc ?
13:41:33 <berick> jeff: ah.  yeah, doesn't really scare me
13:41:41 <gmcharlt> nor I
13:41:45 <jeff> excellent.
13:41:56 <jeff> berick++
13:41:59 <jeff> gmcharlt++
13:42:04 <tsbere> On the "dojo isn't suited for xul" front: Dojo is an HTML JavaScript framework. Why would we expect it to work with non-HTML well? All of our significant dojo interfaces are HTML, not XUL, as it is.
13:42:07 <berick> considering almost every interface I use on a daily basis is web-based, i think we can manage our little corner of the world
13:42:27 <csharp> berick++
13:42:30 <denials> tsbere: because XUL is XML and Dojo deals with XML
13:42:45 <denials> berick++
13:43:05 <gmcharlt> OK, we can get back to this, but moving on so that we touch on everything...
13:43:10 <gmcharlt> #topic Websockets
13:43:16 <Dyrcona> I honestly think the discussion about Dojo in the staff client is moot.
13:43:26 * csharp will need to read berick's posts
13:43:29 <jeff> websockets++
13:43:34 <tsbere> If we go web-based I think we can skip websockets. We don't need 30 websockets per client open.
13:43:38 <jeff> berick++ websockets posts and proof of concept
13:43:47 <berick> tsbere: it would be 1 open connection
13:43:58 <jeff> tsbere: curious, where do you get the 30 number?
13:44:06 <tsbere> berick: One open connection per open window. Cross-window communication isn't that good on web browsers.
13:44:15 <tsbere> jeff: The number of open tabs I have seen whenever I visit a library.
13:44:36 <berick> for starters, we can design a UI that does not require piles of tabs
13:44:40 <berick> like every other web site
13:44:42 <berick> in the world
13:44:45 <denials> heh
13:44:46 <jamesrf> berick++
13:44:53 <csharp> berick++
13:45:01 <tsbere> berick: "Doesn't require" and "staff don't open them" are two different things.
13:45:10 <denials> fwiw, I rarely see our staff having more than a couple of tabs open - cataloging or circ
13:45:13 <tsbere> We already don't need 15 catalog tabs open at a circ desk. I still see it.
13:45:56 <bshum> Yeah we applied a limit to our tabs for the same reason.
13:46:08 <csharp> lots of different workflows in PINES - several use multiple tabs, others just two or so
13:46:25 <phasefx> tabs were a much lauded feature
13:47:11 <denials> anyway - websockets - perhaps in parallel with websockets, would it be possible to make the client (web or xul) less chatty - do more work on the server and return more per request?
13:47:22 <berick> denials: +1
13:47:39 <jamesrf> i have wondered if there would be benefit to do more fieldmappering on the server
13:47:47 <denials> I _think_ that would be a performance win :/
13:47:53 <Dyrcona> denials: That's a topic for another day, I think: Backend Overhaul. :p
13:48:07 <jeff> we cannot make progress by avoiding new technologies due to concerns about possible un-recommended use of the software. if 30 tabs is common and is a resource drain, we can either recommend against, or fall back to typical ajax / non-persistent connections after the first X tabs, etc.
13:48:22 <tsbere> jeff: How do we count tabs?
13:48:23 <phasefx> Dyrcona: I don't think it would be much of an overhaul, just move more logic from staff client to server
13:48:34 <gmcharlt> or do UI work to address whatever drives somebody to open so many tabs at the circ desk
13:48:35 <phasefx> could be entirely new methods that just wrap what's there
13:48:37 <tsbere> I don't know of any way to determine how many tabs of a given website I have open from the website.
13:48:49 <denials> gmcharlt++ # right
13:48:55 <berick> gmcharlt: exactly.
13:49:11 <jeff> tsbere: a detail that is probably too specific for the scope of this meeting, but counting open websockets for a session token comes to mind as one possibility.
13:49:12 <denials> @who wants to hire a UI pro? :)
13:49:13 <pinesol_green> denials: Beyond here be dragons.
13:49:24 <gmcharlt> ... and of course, as we all know, the answer for the circ desk is green screen terminals! ;)
13:49:47 <phasefx> gmcharlt++
13:49:48 <tsbere> As I said, if we go web based I think we need to ditch websockets. If we stay with an actual client I am all for them.
13:49:50 <denials> They are heavy and useful for blunt force
13:50:15 <jeff> jamesrf: i've toyed with the idea of a "thick" gateway / api endpoint to make external integration easier for those who look at the fieldmapper and go "nevermind, we'll just screen scrape"
13:50:24 <jamesrf> tsbere: what is your main objection to web sockets on the web based?
13:50:28 <phasefx> and if we do a hybrid, web for ui, add-on for printing (and websockets)?
13:50:39 <tsbere> jamesrf: Too many open from a single workstation. I already said that. ;)
13:50:49 <gmcharlt> tsbere: I don't think they're mutual exclusive ... a web-only interface could still be heavily dependent on a lot of AJAX
13:50:52 <jeff> tsbere: my understanding of websockets in a web based interface is that they can be an optional enhancement, with fallback. i could be wrong on all counts.
13:50:53 <jamesrf> tsbere: right but i'm sure others have encountered this in using web sockets?
13:51:04 <tsbere> phasefx: I disagree with hybrid, in general, but websockets could be used to communicate *to* the printing client in that case.
13:51:56 <gmcharlt> OK, moving on for the moment
13:51:59 <gmcharlt> #topic Objective third-party performance analysis to identify bottlenecks in the system.
13:52:15 <gmcharlt> kmlussier: could you expand on this?
13:52:17 <kmlussier> After the previous discussion at the last dev meeting, I thought it might be useful if the community had third-party software peformance analysis to identify where the most severe bottlenecks are in the system.
13:52:22 <phasefx> incidentally, the reason for going with xulrunner in the first place was to leverage web-based technologies under the hood while disguised as a local app, plus offline mode and printing
13:52:25 <kmlussier> And while this analysis might include the staff client, it wouldn't be limited to it.
13:52:39 <kmlussier> The main benefit being that any decision we make on changing the staff client or other pieces of the architecutre would be based on evidence generated by this analysis.
13:53:02 <jeff> kmlussier: i'm interested to know if there was anything in particular that led to the use of "third party" and "objective" in the proposal
13:53:34 <senator> haha, not to speak for kmlussier, but we developers can't always smell our own... well it's a meeting so i'll avoid rough language
13:53:44 <kmlussier> Well, I think everyone here has certain biases and particular technologies they are tied too.
13:53:56 <krvmga> senator++
13:53:57 <phasefx> nor do we often eat our own dogfood
13:54:05 * denials supports anything, as long as it runs on Fedora
13:54:07 <Rogan_> kmlussier++ for being polite
13:54:09 <ktomita> senator++
13:54:11 <denials> kmlussier++
13:54:17 * Dyrcona eats his own dog food, quite literally.
13:54:20 <kmlussier> We have a lot of libraries that are anxious for performance improvement.
13:54:22 <Dyrcona> kmlussier++
13:54:26 <ktomita> kmlussier++
13:54:28 <jeff> kmlussier: i would be in favor of more performance analysis / staff interface instrumentation / etc, but (other than "there has not been a comprehensive effort by the community yet" (perhaps unfair, especially in light of recent memory leak work), is there a reason you think it would need to be "objective third party"?
13:54:33 <kmlussier> And my main concern is that we promise that a solution is coming 6 months down the road.
13:54:33 <csharp> kmlussier++
13:54:35 <tspindler> kmlussier++
13:54:54 <kmlussier> But, when it's implemented, it leads to very little improvement becaue there is a bigger issue behind the scenes that has nothing to do with the staff client.
13:54:55 <jeff> kmlussier: okay, so developer biases for favorite methods/tools... anything else? :-)
13:54:55 <denials> jeff: 1) avoids biases 2) avoids getting derailed in "oh another bug to fix"
13:55:11 <krvmga> jeff: my own understanding is just to have it done by someone who doesn't have a dog in the fight, so to speak.
13:55:12 <phasefx> we could probably get a lot of win by hiring Mozilla developers to poke at our use of xul, but it wouldn't be all that objective
13:55:13 <jeff> cool. thanks for addressing my curiosity.
13:55:44 <jamesrf> kmlussier++
13:55:51 <jeff> it probably goes without saying that "third party objective" == money? do you have anyone in mind at this point?
13:56:09 <kmlussier> No, I don't have anyone in mind.
13:56:24 <gmcharlt> but what third party exists that wouldn't have a bias for any particular technology or solution but *would* have an interest in Evergreen?
13:56:31 <jasonb_> I think a massive profiling of the server code while serving client requests would help as much as anything. The machines I'm using can't be made this slow by any sane combination of JavaScript, but a server that doesn't respond immediately makes the client seem slower than it really is.
13:56:31 <kmlussier> I know MassLNC could contribute *some* funds, but I think it's important that if this were to happen, it's a community project, not a masslnc thing.
13:57:15 <jasonb_> But I'm in no position to actually perform that, just mentioning it. :/
13:57:27 <tsbere> I agree with the fact that some of the staff client issues are very likely actually server side code issues.
13:57:39 <gmcharlt> I think finding/hiring such a person or entity would have to be handled very carefully to make sure that the results (a) got buy-in from whoever would implement the recommendations and (b) actually participate in the community, at least during the course of their project
13:57:40 <phasefx> and redundant network calls to the server
13:57:40 <jamesrf> Sitka/BCLC would support such a project as well
13:57:41 <jeff> I would like to have more instrumentation overall (we already have some examples, like the timing debug in tpac) for evaluating new code / code changes with performance in mind.
13:57:43 <denials> gmcharlt: fair enough, we might get a recommendation that SQL Server would fix all of our problems :)
13:58:13 <berick> perhaps we could preceed any 3rd-party invovlement with our own list of ideas?  i'm sure we have them and we'll probably find a lot of agreement
13:58:16 <gmcharlt> that said, I don't disagree with the concept of getting help from folks who specialize in (say) UI or performance issues
13:58:20 <tspindler> denials: or oracle
13:58:50 <jeff> ("test cases are hard, performance test cases doubly s[l]o[w]"?)
13:59:04 <gmcharlt> and certainly things like third-party security audits (thanks denials and Conifer!) are useful
13:59:17 <denials> But 1) I don't think we have the capacity to do this kind of work in our existing community, heroic weekend efforts that lead to memory leak fixes aside
13:59:53 <denials> 2) We might also lack the expertise to do a good job
14:00:00 <csharp> denials++
14:00:09 <csharp> Evergreen has a huge learning curve
14:00:20 <csharp> they might spend 6 months just learning how it works
14:00:26 <gmcharlt> csharp: indeed
14:00:28 <denials> csharp: true
14:00:33 <ktomita> csharp: agreed
14:00:36 <krvmga> csharp++
14:00:38 <wolf29> csharp++
14:00:42 * paxed looks around and pretends he knows something about evergreen.
14:00:48 <dbwells> I wonder if it would be worth dedicating a whole release cycle to performance issues, rather than new features.  So 2.5 (for example) doesn't get any new features.
14:00:50 <csharp> paxed++
14:00:53 <denials> ideally we would come out of this with a set up that would be repeatable
14:01:14 <gmcharlt> dbwells: I find that an interesting idea ... but would there be community support and funding?
14:01:14 <mrpeters-isl> dbwells:  not a bad idea
14:01:18 <denials> (if the proposal went forward) so that we could measure progress
14:01:26 <tspindler> dbwells:  I think that makes some sense too, a lot of work done on adding features but not addressing long term problems
14:01:41 <denials> dbwells: it would be a really tough sell :/
14:02:04 <tspindler> no one wants to pay for "bug" fixes if you can call it that
14:02:24 <ktomita> a performance test suite would be something the entire community benefits from
14:02:36 <jasonb_> Bugs aren't working properly. Performance improvements are a different thing.
14:02:47 <tspindler> I used the term loosely
14:02:51 <mrpeters-isl> tspindler:  the argument is likely that no devs get paid if they're not writing new features
14:03:20 <kmlussier> dbwells: I like the idea too, but, looking at my list of wanted enhancements, it would indeed be a tough sell.
14:03:31 <denials> performance improvements you can pitch and get paid for, but saying "no new features" would be tough
14:03:34 <wolf29> mrpetersisl: unless they are specifically charged with clean-up
14:03:35 <kmlussier> But I'm also concerned that the enhancements we keep sponsoring are just making performance worse.
14:03:41 <gmcharlt> which does tie into a general oversight committee discussion about fundraising, including for general infrastructure work
14:03:53 <mrpeters-isl> who charges them to only work on patches, wolf29?
14:04:04 <denials> in theory, you could pitch "unit tests, regression tests, system tests, performance tests" and get paid for that too
14:04:15 <ktomita> denials++
14:05:14 <wolf29> mrpeters-isl: if you hire someone to do a job, you pay them to do it, is all I am saying. :-)
14:05:20 <denials> ktomita: http://coffeecode.net/archives/228-Got-funds-for-enhancing-Evergreen-Looking-for-places-to-spend-it.html :)
14:05:38 <Rogan_> I can't speak for the oversight committee obviously but I do like the idea of organizing fund raising for things like this and QA.
14:05:38 <gmcharlt> to suggest a possible action item, does somebody (or somebodies) want to research concrete people and/or entities offering indepndent experitise?
14:05:47 <smyers_> The low hanging fruit for performance is databse queries. Cataylst and Commandprompt just finshed fixing holds counts for KCLS. We took 4-5 second queries and turning them into 4-5ms queries
14:06:12 <jeff> smyers_: great! was there a launchpad bug with that issue and fix? sounds quite promising.
14:06:17 <kmlussier> gmcharlt: I could work on it, but I think I would need help.
14:06:18 <DPearl> smyers_++ I think you are on the right track
14:06:25 <Rogan_> Halting feature development for refining is an easy sell to my users in terms of being a good idea but I don't know if they'll put funds directly into it (they will my time though!).
14:06:27 <ktomita> smyers_++
14:06:40 <moodaepo> jeff++ launchpad_entries++
14:06:43 <stevenyvr2> kmlussier: an evidence-based analysis could be done by the community, not necessarily by a 'third-party'; I think the key is to use the relevant tools to gather the evidence.
14:07:09 <denials> smyers_++ # yep - bug entry would be nice as mentioned!
14:07:15 <kmlussier> I liked berick's ideas of coming up with a list of ideas before finding somebody.
14:07:27 <eeevil> smyers_: did you add coverage for all the hold types, then?
14:07:53 <smyers_> We are looking at how to implement the fix into latest as KCLS is 2.1...2.2
14:08:01 <jeff> stevenyvr2: i do like the idea of the community doing (at least) some initial ground work in advance of hiring someone and saying "make this faster"
14:09:05 <denials> jeff: I think kmlussier's proposal was to have the 3rd party say "Here are the bottlenecks" - and stop there
14:09:39 <berick> that was my understanding as well
14:09:42 <denials> hiring someone to fix those bottlenecks, or fixing them within existing community resources, would be a different matter
14:09:42 <jeff> ah, right. i guess revised that would be "tell us where this is slow" :-)
14:09:46 <DPearl> We may be looking at more than one person. There are a lot of fronts to attack here.
14:10:03 <kmlussier> Yes, exactly. I think we would need to make it clear up front that they won't be getting further development work out of it.
14:10:15 * denials said 3rd party there to enable it to be an organization :)
14:10:36 <acoomes> DPearl++
14:10:40 <DPearl> That's my kind of party!
14:10:49 <denials> client, opensrf, database, ah, only three fronts :)
14:10:53 <jeff> denials: yeah, "someone" in my usage above was not meant to exclude organizations :-)
14:11:12 <berick> 3rd-party + community input -> list o things -> launchpad
14:11:22 * gmcharlt is wondering what we can do to increase expertise *within* the community about performance and UI
14:11:29 <ktomita> berick++
14:11:34 <kmlussier> berick++
14:11:36 <jeff> denials: you forgot Windows antivirus / endpoint protection products and proxy servers! ;-)
14:11:38 <Dyrcona> gmcharlt: Study?
14:11:40 <acoomes> berick++
14:12:07 <stevenyvr2> I think part of the problem is the lack of test suites for the software, not just for performance, but for functionality. We need test suites in a test framework that can be repeated.
14:12:10 <denials> gmcharlt: expand time?
14:12:17 <gmcharlt> Dyrcona: indeed, we certainly all have a responsible to do that ... but it may be helped by also investigating training options?
14:12:21 <denials> stevenyvr2: I _knew_ I liked you.
14:13:09 <stevenyvr2> If there were test suites/test framework that have good coverage, we would have all the evidence we want.
14:13:31 <jeff> gmcharlt: knowledge sharing? study groups? more developers writing documentation? lots of possibilities, but short of denials's time dilation idea i'm not sure of how to encourage said possible options.
14:13:43 <acoomes> stevenyvr2: Testing suites like that would be a good argument for web-based rather than staff client
14:13:44 <JennB> Hello Evergreeners, I have a question. I just created noncataloged types (paperback, magazines etc) in the editor in Local Admin. I then went to check out and don't see my new ones there. When I go back to the editor, my items are there. How do I get them to appear under checkout?
14:14:15 <Dyrcona> JennB: There's a meeting in progress.
14:14:18 <gmcharlt> jeff: right, but I do think we need to think about it; after all, things like test suites don't happen without time commitments either
14:14:18 <jeff> JennB: hi! not to pile on, but we're in the middle of a meeting -- if you could stick around and ask your question after the meeting, or post to the evergreen mailing list for an answer...
14:14:55 <JennB> Oh Im very sorry! I didnt realize.
14:15:31 <gmcharlt> so dragging us back to the agenda
14:15:32 <ktomita> test suites would be time consuming but the benefits would be great
14:15:46 <acoomes> ktomita++
14:15:49 <gmcharlt> I think we've had a good discussion of various options
14:16:04 <denials> 2.5: All performance; all test coverage; all honing of our awesome developer skills
14:16:12 <dbwells> denials++
14:16:18 <stevenyvr2> Test suites could be built up over time; the key is to have a good framework.
14:16:19 <gmcharlt> but I'm now opening the floor to proposals for action items
14:16:20 <ktomita> denials++ especially on the last one
14:16:31 <acoomes> denials++ yes!
14:16:59 <mrpeters-isl> JennB:  check PMs
14:17:07 <jeff> mrpeters-isl++
14:17:28 <gmcharlt> #topic Next steps?
14:18:23 <eeevil> jeff: [since it fits in with next steps, I'll hit enter...] entities writing features or fixing issues (bugs, performance, otherwise) could be strongly encouraged at the point of a commit bit to provide more documentation earlier. there's a not-insubstantial cost (effort, money, delay) to that, of course, regardless of the entity producing the code
14:18:46 <jamesrf> one idea might be to use cucumber to leverage the super awesome docs group to allow them to write some test cases
14:19:12 <jeff> Work Together. Work in Public. I'm interested in several aspects of this, and have some ability to devote time. It would be good to know others interested in similar bits, and work / study together to further those goals/interests.
14:20:00 <eeevil> have we veered away from the point of the meeting, though, of "future of the staff client"?
14:20:02 * denials seems to recall joelewis writing a bunch of unit tests for his dojo.next work...
14:20:02 <krvmga> jamesrf: interesting
14:20:19 <ktomita> jeff: evergreen is a community after all.
14:21:02 <gmcharlt> eeevil: we have indeed, a bit, given that performance in general has been discussed as a important issue
14:21:19 <denials> eeevil: I would say that if the future of the staff client requires decisions based on objective criteria, and based on the level of skill / capacity of the community to overcome performance problems / UI problems, then it's related to the topic
14:21:30 <gmcharlt> but that raises a question: of the specific *staff client* proposals made during this meeting, is there a consensus on any approach?
14:21:39 <bradl> Java
14:21:42 * bradl runs
14:21:44 <eeevil> denials: it's certainly related, yes
14:22:23 <eeevil> gmcharlt: based on my understanding of the "camps", I'd say no. for some it seems black or white.
14:22:51 <jeff> i'm interested in experiments with browser-based, clientless staff interfaces. i'd like to work with others who might share those same interests. i don't suggest that this mean "xulrunner staff client is dead, the new web-based UI will be ready in a few months"
14:22:52 <eeevil> but we have more cards on the table now
14:23:17 <berick> jeff: ditto.
14:23:37 <wolf29> jeff: I am interested in that as well
14:23:41 * phasefx wonders if folks really would tolerate a green screen
14:23:42 <mrpeters-isl> i really fear the browser imcompatibility issues if we mvoe to a web based UI
14:23:54 <gmcharlt> my sense is that we're at a point where experimentation, hopefully with some concrete code, is in order on various fronts
14:24:01 <jeff> i like the idea of moving toward less remote xul (for many of the reasons stated earlier) in the staff client, but i do not have strong xul chops (other than chopping out unused interfaces), so i can't say i'll be much help there, but as i mentioned earlier it seems like a good direction to move toward, since nobody is saying "kill the xulrunner client TODAY"
14:24:07 <krvmga> movement to a dojo-less client?
14:24:09 <mrpeters-isl> yeah, we can tell libraries to install a particular browser/version but it's much easier to say "install this client"
14:24:27 <jeff> krvmga: i've no strong opinion on dojo in the staff client.
14:24:42 <alexlazar> mrpeters-isl: I think it's not as horrible as you imagine
14:24:53 <tspindler> we would never be able to enforce any kind of browser standard in our network
14:24:53 <jeff> krvmga: there's "remote xul" and "local xul", and i think the reasons for shifting toward more "local xul" bear further investigation.
14:24:56 <alexlazar> with browser incompatibilities
14:25:00 <gmcharlt> would it be fair to say that there is a consensus that moving await from remote XUL is a good idea in the short term?
14:25:03 <jamesrf> mrpeters-isl: there are tools like modernizr that could help and we could always put a big alert saying "your browser isn't the best"
14:25:03 <mrpeters-isl> we've got 100+ libraries and now we have to support their web browser?  no thanks
14:25:09 <krvmga> never matches my sweet imagination :)
14:25:13 <denials> gmcharlt: I would agree with that
14:25:21 <csharp> gmcharlt+1
14:25:40 <jeff> gmcharlt: +1 moving away from remote xul
14:25:45 <tspindler> mrpeters-isl: ditto here
14:26:16 <krvmga> +1 moving away from remote xul
14:26:26 <dbwells> gmcharlt: +1 (despite the debugging pain)
14:26:32 <gmcharlt> OK, so I'd like to call for the sense of the room on the following statement: in the short term, Evergreen devs are encouraged to start moving staff client interfaces away from remote XUL
14:26:43 <mrpeters-isl> gmcharlt: what is the benefit
14:26:51 <mrpeters-isl> i missed much of this talk
14:26:56 <mrpeters-isl> just speed?
14:26:58 <eeevil> mrpeters-isl: loading time decreased
14:27:06 <tsbere> mrpeters-isl: Less network traffic downloading the xul files, especially ones that get loaded with query string arguments
14:27:07 <denials> mrpeters-isl: scrollback for more, but performance and less hackery
14:27:57 <mrpeters-isl> i guess i have no objection then
14:28:17 <jeff> in addition to traffic/performance/caching benefits, "remote XUL" is far less supported than it used to be in xulrunner, requiring (denials just said it) hackery.
14:28:26 <mrpeters-isl> yeah, i recall that part
14:29:12 <mrpeters-isl> why was remote xul chosen in initially?  just wondering why we didn't go for local xul in the beginning.
14:29:29 <mrpeters-isl> just trying to understand what has changed the philosophy
14:29:41 <jamesrf> mrpeters-isl: mozilla stopped supporting remote xul based on security concerns
14:29:49 <phasefx> ease/speed of development.  We were making changes nightly for PINES
14:30:02 <mrpeters-isl> thats what i was looking for, thanks phasefx
14:30:06 <berick> mrpeters-isl: because it gave us one of the main benefits of a web app -- remote deployment
14:30:06 <phasefx> that changed as remote xul became a red-headed stepchild for Mozilla
14:30:15 <mrpeters-isl> sure, i understand now
14:30:25 <jeff> in the long-ago past, we (our library system, not the larger community) used remote XUL to have one stock client behave differently in certain interfaces based on server host/hostname that it was connecting to, and to deploy changes within the staff client without a client install / update being required.
14:31:07 <gmcharlt> since we're at an hour and a half, i'll just do this
14:31:10 <gmcharlt> #action Evergreen devs are encouraged to start moving staff client interfaces away from remote XUL
14:31:48 <gmcharlt> and unless I hear any other items for the formal part of the meeting, I'll plan on ending in a minute
14:31:58 <moodaepo> gmcharlt++
14:32:03 <gmcharlt> obviously, it's clear that this is going to be a long-running discussion
14:33:06 <bshum> gmcharlt++
14:33:07 <gmcharlt> #endmeeting