Dev chat reminder (and free ponies)

[Robert Kaye]

Remember that we've got our weekly dev chat* on Monday July  20 in IRC
in  #musicbrainz-devel on irc.freenode.net . We're going to meet for
about 1 hour at 8pm UK, 9pm mainland  europe, THREE pm EST, NOON PST.

We'll review progress on NGS and review our approach to the new edit UI.





* The will be no ponies. :(

--

--ruaok      "Vague, but exciting..." -- Mike Sendall on the WWW  
proposal.

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net






_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Kuno Woudt-2]

On Sun, Jul 19, 2009 at 08:17:40PM -0700, Robert Kaye wrote:
> Remember that we've got our weekly dev chat* on Monday July  20 in IRC
> in  #musicbrainz-devel on irc.freenode.net . We're going to meet for
> about 1 hour at 8pm UK, 9pm mainland  europe, THREE pm EST, NOON PST.
>
> We'll review progress on NGS and review our approach to the new edit UI.
>
> * The will be no ponies. :(

Like the previous weeks, still mostly hardcore NGS development going on,
but here are the logs for anyone interested :)

-- kuno / warp.

20:45 -!- ruaok changed the topic of #musicbrainz-devel to: agenda: review, NGS edit ui, what else?
21:00 <@ruaok> <BANG>
21:00 <@ruaok> lets start the meeting!
21:00  * pronik logs in from local mongers meeting
21:00  * aCiD2 waves
21:00 <@ruaok> luks: ah. and is the module still being maintained on pgfoundry?
21:00 -!- murdos [n=Aurelien@...] has joined #musicbrainz-devel
21:00 <@ruaok> aCiD2: take away the review for last week!
21:00 < aCiD2> sure thing
21:00  * ruaok waves at murdos
21:01 < luks> ruaok: not really maintained, but it's there
21:01 < murdos> hi! Am I late, or just in time? :)
21:01 <@ruaok> murdos: perfect timing.
21:01 < aCiD2> Fairly slow here, I got a few more bits in that are unrelated to the edit ui -- we can search for edits, with fairly expressive search parameters
21:01 -!- pony [n=pony@...] has joined #musicbrainz-devel
21:01  * brianfreud_ waves
21:01 <@ruaok> luks: do any changes need to be made to get it to work with pg 8.4?
21:01 < aCiD2> Also, I refactored our test suite to run faster, which is more maintainence work - but much needed
21:01 <@ruaok> pony: I think you might be in the wrong place.
21:01 <@ruaok> moose dominate here. :)
21:01 < aCiD2> :D
21:01 < luks> ruaok: I don't think so, it works fine with 8.3
21:01 < pony> :P
21:01 <@ruaok> luks: ok.
21:02 < pony> don't see no moose here
21:02 < brianfreud_> I've got a functional and up to date server finally, I think :)
21:02 < luks> ruaok: the patched version we are currently using just renamed dbmirror_Pending* to Pending*
21:02 < aCiD2> We moved forward with the release editor too, and we've all finally agreed on how it should look. So, I started work on that by providing the edit type to edit releases, and a very basic web interface, with the hope brian can take it from there :)
21:02  * ruaok nods at luks
21:02 < aCiD2> I have some questions that came up while I wrote $EDIT_RELEASE_EDIT, but we'll come to the later
21:02 <@ruaok> sounds good aCiD2
21:02 <@ruaok> luks, how about you?
21:02 < aCiD2> good, but still a bit slow for my liking :)
21:03 -!- pony [n=pony@...] has quit ["ponies!"]
21:03 <@ruaok> aCiD2: anything blocking you from progressing faster now?
21:03 < luks> I've fixed some reference counting issues in the upgrade script and triggers (still waiting for review)
21:03 < luks> and started working on the admin/ scripts
21:03 < brianfreud_> yes, I hope to have a functional prototype within 2 days for people to comment on - perhaps we could schedule a quickie meeting Weds or so, to review that UI (trying to avoid the newUI problem from last time :) )
21:03 < luks> export/import
21:04 <@ruaok> luks: I just reviewed a couple of patches.
21:04 < aCiD2> ruaok: nothing blocking me really, I'm just a bit unsure exactly what I should be focussing on
21:04 < aCiD2> my work is sort of meandering, and it stalls me a bit having to decide what to do
21:04 < luks> I'd like to get export, import and replication done
21:04 <@ruaok> luks: yes, good. we need to test that extensively.
21:04 <@ruaok> aCiD2: lets chat a little after the meeting and make a personal roadmap for you, ok?
21:05 < brianfreud_> ruaok: for the agenda, could you add data passing in/out of the edit ui?
21:05 <@ruaok> luks: anything blocking you? seems like you're making good progress.
21:05 < aCiD2> sounds perfect :)
21:05 <@ruaok> aCiD2: great.
21:05 <@ruaok> brianfreud_: lets chat about that when we get to the UI portion.
21:05 < luks> ruaok: not really, I'll continue to work on the upgrade/maintaince side
21:05 <@ruaok> sweet.
21:06 < luks> I hope to do the first version of AR migration this week
21:06 <@ruaok> nice. It will be good to see progress on that. I totally failed in that regard. :-(
21:06 <@ruaok> brianfreud_: anything else to add to your progress from last week?
21:06 < luks> I started working on it, because I want to add cover art support
21:07 < luks> and it depends on proper AR migration
21:07  * ruaok nods
21:07 < brianfreud_> nothing functional to see yet; I have a good idea of how the UI should happen though, and finally a functional server - I'm hopeful to have an interactive mockup / proto ready w/in 48 hours
21:08 < aCiD2> cool, just a quick note, I updated my git mirror, if you want to grab anything off that
21:08 < brianfreud_> :P  /me just finally finished git-svn
21:08 <@ruaok> I hope your work follows the mock-ups that we created in the last week.
21:08 < brianfreud_> yes
21:08 <@ruaok> sweet.
21:08 <@ruaok> anything blocking you?
21:08 < brianfreud_> not at the moment, but data passing will be an eventual decision we need to make
21:09  * ruaok nods
21:09 < aCiD2> that's not an issue, I've covered that I believe
21:09 < aCiD2> but we can talk about that neared the time
21:09 < aCiD2> nearer*
21:09 <@ruaok> my weeks was a bit of a mish-mash.
21:09 <@ruaok> working on board related stuffs, google donation stuffs,
21:09 <@ruaok> some server related stuff
21:09 < brianfreud_> just to ask, while we're there, any objections to just defining a json array object to pass in data?  I can pass it out however is best for the server to handle it.
21:10 <@ruaok> dealing with amplified music services (or rather being frustrated with them).
21:10 <@ruaok> brianfreud_: in a minute, please.
21:10 < brianfreud_> np
21:10 < aCiD2> brianfreud_: pm me about this implementaiony stuff after the meeting and we'll work it out
21:10 < warp> ruaok: whats amplified music services?
21:10 < warp> +'
21:10 < brianfreud_> AMS == the new MIP?
21:10 <@ruaok> I've also taken over luks WS patch and am working on ironing out XML schema bits. or at least naming.
21:10 <@ruaok> brianfreud_: yes
21:11 < pronik> any news on that front?
21:11 -!- ruaok changed the topic of #musicbrainz-devel to: agenda: NGS UI issues, AMS & cd toc stuff
21:11 <@ruaok> pronik: sorta. I've added an agenda item for that.
21:11 < pronik> ok, got it :)
21:12 < aCiD2> push @agenda, 'creating works, mediums, and more'
21:12 <@ruaok> the last bits of my update will follow in the AMS discussion.
21:12 <@ruaok> brianfreud_: did aCiD2  just take care of your UI issue?
21:12 -!- ruaok changed the topic of #musicbrainz-devel to: agenda: NGS UI issues, AMS & cd toc stuff, creating works/mediums/more
21:12 < brianfreud_> no
21:12 <@ruaok> then take it away.
21:13 < brianfreud_> Ok.
21:13 < brianfreud_> In an inlined editor, my concept is that editing takes place in a js-modified (js loaded on demand, so no pageweight++) version of the page.
21:13 < brianfreud_> But that means either js making the form fields, or the server *always* including them.
21:14 < brianfreud_> The latter doesn't make much sense to me.
21:14 < aCiD2> When I wrote the artist credit editor, I found it much easier for the server to spew out all the required fields, and the JS to just move the around as it needed to
21:14 < brianfreud_> The negative, then, is that, when we want to pass data into editing forms (url args, etc) from the server, we have to get that data from the server into js.
21:14 < brianfreud_> aCiD2: easier, but it bloats the pages, every single time, a good deal
21:15 <@ruaok> I think emitting a few fields to support editing isn't that big a deal. compared to all the tables we used to use it should be a small amount of data, no?
21:15 < brianfreud_> we're dealing with very redundant HTML snippets; easy to insert them only as needed.
21:15 < brianfreud_> no
21:15 < brianfreud_> you'd prob be looking at doubling the size of every single page
21:15 < aCiD2> I don't think it adds any bloat that you can claim requires weird JS stuff
21:15 < aCiD2> Not without some benchmarks or statistics...
21:15 < luks> note that it's not every single page
21:15 < brianfreud_> how is inserting into div Foo 1..n copies of the same HTML "wierd JS"?
21:15 < luks> it's every edit page and I'm happy with that
21:16  * ruaok is with luks
21:16 < brianfreud_> every page is an edit page...
21:16 < aCiD2> brianfreud_: because you're having a problem with how to get data into them, when HTTP just does it for you? :)
21:16 < aCiD2> When we go live, we're going to have forward proxies, data compression and all sorts of other fancy stuff that makes a few extra bytes in some static html much less of an issue
21:16 < brianfreud_> aCiD2: my thought was, when we do need to pass data, just have the server include into the page a js / json array, for js to then parse and populate into the fields
21:17 <@ruaok> that seems silly to me.
21:17 < aCiD2> I'm going to have vote -1 on that until I see a more conventional way not working
21:17 <@ruaok> I think the gzip compression is going to be more effective and our code remains simpler.
21:17 < brianfreud_> aCiD2: it just doesn't make a lot of sense to me to always be including a bunch of hidden fields (1 for each artist, 1 for each track title, one for each label, each cat #, each everything...)
21:17 < aCiD2> sure it does
21:18 < aCiD2> it's a field, you include the field, makes sense to me
21:18 < brianfreud_> well, I can do it either way.
21:18 < brianfreud_> But I think the way I'm describing makes a lot more sense.
21:18 < aCiD2> It violates luks' mantra of do the simplest thing
21:18 <@ruaok> and consider the fact that the edit pages don't constitute a large amount of our bandwidth... the WS does.
21:18 < aCiD2> which I have come to love *so much*
21:18 < brianfreud_> Would you object to my at least putting it into a showable form, so you three can make a more informed decision?
21:18  * ruaok nods at simple
21:18 <@ruaok> sadly, simple is hard
21:19 < aCiD2> brianfreud_: personally, I'd say don't waste time on that, and just work on the normal way
21:19 < brianfreud_> ruaok: yes, but all those hidden forms still cause page load delay, bandwidth or not.
21:19 < aCiD2> ruaok: simple is not hard in this case
21:19 < aCiD2> brianfreud_: again, you have no backup for that claim
21:19 <@ruaok> brianfreud_: I disagree. those few form fields wont make much difference.
21:19 < aCiD2> no backup that it makes a substantial difference
21:19 <@ruaok> brianfreud_: please keep it simple.
21:19 <@ruaok> if we find its too slow, we'll fix it in a later release.
21:19 < brianfreud_> aCiD2: I actually do - +1 element leads directly to longer render time.  You're talking +many elements.
21:19 <@ruaok> my guess is that it will be so much faster than before, people will cheer.
21:20 < brianfreud_> sigh
21:20 < aCiD2> yes, and I agree it is "slower" i'm saying you don't know if it's *substantially* slower
21:20 < pronik> make it slower, then faster againa
21:20 < aCiD2> and that requires running on musicbrainz.org, and doing user studies
21:20 < brianfreud_> I'm talking something that would be quite easy to mock up; all I ask is that you guys consider it, esp since it'd be my boat to make it work.
21:20 < aCiD2> pronik++, it's all about iterative development
21:20 < aCiD2> brianfreud_: time of the essence
21:20 < aCiD2> is of*
21:20 < brianfreud_> honestly, I think you'll find it a simpler solution, once you see and understand it.
21:20 <@ruaok> brianfreud_: we just considered it.
21:20 < luks> you know, 'premature optimization is the root of all evil'
21:20 < brianfreud_> yes
21:20 <@ruaok> I am not keen on the added complexity. I can't see the benefit in it.
21:21 < brianfreud_> you're optimizing off the cuff :P
21:21 <@ruaok> brianfreud_: are there other topics we should discuss?
21:21 <@ruaok> UI questions like these?
21:22 < brianfreud_> Wait, please? Please explain to me...  Honestly, how is it easier and better to include a bunch of form fields and layout, all identical to each other, rather than having js insert them, only as needed?
21:22 <@ruaok> its easier for anyone to jump into the code and make changes.
21:22 < aCiD2> brianfreud_: I could give you a lot of reasons, but really, you've seen enough -1s now to know we are not going to go on with this...
21:23 < brianfreud_> sigh
21:23 <@ruaok> the system you're proposing adds one layer of complexity that makes it harder for people to work on the site.
21:23 < brianfreud_> actually, it makes it simpler, but I can see that noone's really willing to consider it.  :(
21:23 <@ruaok> brianfreud_: its very basic: simple vs complex. We want  simple. the entire NGS codebase is SIMPLE.
21:23 < aCiD2> no, it does not make it simpler.
21:23 <@ruaok> brianfreud_: I just considered it.
21:23 < brianfreud_> ETI = simple
21:23 < aCiD2> if I want a form, I use <form> and I use <input>. that is simple
21:23 <@ruaok> we all did.
21:23 < brianfreud_> this is the definition of ETI
21:24 < aCiD2> I do not use <form>, javascript, lazy loading, including fields later, munging POST data into JSON and other weird stuff
21:24  * brianfreud_ gives up
21:24 < aCiD2> brianfreud_: we're doing this to save you time and get something that works
21:24 < pronik> brianfreud_ just doesn#t want to work on perl ;)
21:24 < brianfreud_> All I asked was that you be willing to wait a day or two for me to work both up, and then take a look at it, to make an informed decision.
21:25 < aCiD2> he doesn't need to work on perl
21:25 < aCiD2> a day or two that could be spent on work that we're almost unconditionally going to accept
21:25 < pronik> brianfreud_: let us discuss the matter separately
21:25  * ruaok nods at aCiD2
21:25 < brianfreud_> I see the rush to decide it, having seen neither, as itself premature optimization.  It actually makes the js more, not less complex, and it bloats the html.  But it's been decided, so I'll do it your way.
21:26  * ruaok respectfully disagrees
21:26 <@ruaok> any other NGS UI topics?
21:27 < aCiD2> nothing ui here
21:27 < brianfreud_> not from me.
21:27 <@ruaok> ok.
21:40 -!- ruaok changed the topic of #musicbrainz-devel to: agenda: creating works/medums/more
21:40 <@ruaok> aCiD2: works, etc. take it away!
21:40 < aCiD2> ok
21:40 <@ruaok> thanks, brianfreud_
21:40 < aCiD2> brianfreud_: all good?
21:41 < brianfreud_> I'll do it your way, as I said.  :)  Only q is how you guys want me to be sending you the data from the forms :)
21:41 < pronik> after the meeting please :)
21:41 < aCiD2> perl script or something to create a POST request I expect, or something
21:41 < aCiD2> anyway
21:42 < aCiD2> I was killing some time today by writing a few more edit handlers (just writing edit work as we speak) and I thought about Edit::Work::Create, Edit::ReleaseGroup::Create etc and i'm wondering - how will the user actually create works, release groups, tracklists and other things
21:42 < aCiD2> basically the question is - which need a "create" edit type, and which would automagically be created
21:43 <@ruaok> RG automatically, as we already do.
21:43 < brianfreud_> Are these edit handlers to be all behind the scenes now, js passing data somehow, the server processing the data passed, and calling the appropriate edit handlers?
21:43 <@ruaok> work, not so sure.
21:43 <@ruaok> mediums yes, as part of a release add.
21:44 < aCiD2> brianfreud_: huh? Edit handlers are just bits of Perl code that modbot calls and stuff
21:44 <@ruaok> at least that is my impression.
21:44 < aCiD2> ruaok: but would adding a medium be a separate edit? I think yes, for atomicity - and we work on "grouping" edits together
21:44 < brianfreud_> aCiD2: yes, but they won't be tied to a specific page POSTing something
21:44 < aCiD2> brianfreud_: well, one page can create many edits, if that's what you mean
21:45 < luks> brianfreud_: they don't work with HTTP at all
21:45 < brianfreud_> ok
21:45 <@ruaok> aCiD2: Yes, I think that is accurate. I think that will suck until the new edit system....
21:45 < aCiD2> ok
21:46 <@ruaok> ok then.
21:46 < aCiD2> cause basically what I need (and I think this is what we'll discuss after the meeting) is to work out exactly what edit types I still need to write
21:46 <@ruaok> we done with official topics?
21:46  * ruaok nods at aCiD2
21:46 < aCiD2> sure
21:47 <@ruaok> murdos: how about you? how are things in your world?
21:47 < murdos> quiet and lazy... :)
21:47 <@ruaok> I saw the recent search server patches -- thanks!
21:47 < murdos> slowly working on the lucene java search server
21:47 < murdos> yes
21:47 <@ruaok> and I am worndering if you'd like to work on the search servers more to adapt them towards NGS?
21:48 < murdos> yes, but I would like to finish the current one
21:48 <@ruaok> makes sense. however, given the schedule, I am not sure we'd even get a chance to release the current version.
21:49 < murdos> when is ngs release planned?
21:49 < aCiD2> End of aug
21:49 <@ruaok> beta is aug 31.
21:49 <@ruaok> but the actuall rollout will come later. I suspect a longer beta cycle than normal.
21:50 <@ruaok> we literally are changing EVERYTHING. which makes rolling it out a bit of a challenge.
21:50 <@ruaok> murdos: lets chat more as you reach completion on the current plan.
21:50 <@ruaok> I think adapting the servers for NGS isn't that much work.
21:50 < murdos> that's also why I would like to make the lucene java server live before ngs
21:51 <@ruaok> almost as much work on the mb-server side as on the search side.
21:51 < murdos> make changes gradually...
21:51 <@ruaok> murdos: agreed. it'd be nice if we can accomplish this.
21:51 <@ruaok> ok. one last point:
21:52 <@ruaok> our next summit will be in germany. Nürnberg to be exact. November is the likely date.
21:52 < warp> awesome!
21:52 < aCiD2> :o
21:52 < aCiD2> exciting stuff :)
21:52 <@ruaok> but I wont really pin down an exact date until we can see the light of day of NGS.
21:52 < brianfreud_> :)
21:52 < warp> i'll save up my days-i-can-take-off-from-work for november then.
21:52 <@ruaok> and as part of the google donation, I think metabrainz can sponsor a couple of people to go to the summit.
21:53  * ruaok hopes murdos will jump on a train and take part
21:53 < aCiD2> more the merrier :)
21:53 <@ruaok> ok, enough for today.
21:53 <@ruaok> onward to more discussion in the main channel.
21:53 < murdos> ruaok: sure, germany is not far from france :)
21:53 <@ruaok> thanks everyone!
21:53 <@ruaok> YESS!
21:53 < warp> ruaok: thanks!
21:53 <@ruaok> <BANG>



_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[bogdanb]

I just wanted to post a little note on the snippet below. (There was a
bit more in the log.)

The arguments against brianfreud's optimization seemed to be only
“don't want to complicate code, that bandwidth isn't hurting us much”.

Did anyone consider that it's hurting some users? I'm not asking
rhetorically. Editing a full release, especially a big one, is quite
slow even on my best machine. Opening, e.g.,
http://musicbrainz.org/edit/album/editall.html?releaseid=19446 takes
six seconds or more. Admittedly my ADSL is crappy, but not everybody
has FTTH. When I'm on my laptop it's much worse, and the net
connections I use are sometimes worse than mine.

Somebody mentioned compression. That's nice, too, but remember that
the browser still has to parse the de-compressed HTML. And it has to
keep the DOM in memory, and I've never seen a browser that didn't
re-flow the MB edit <table/> several times during the page load time,
and once at the end. Having the visible table in one part of the page
and the hidden (invisible) data at another (rather than interleaved in
hidden speed) will speed up parsing and displaying of the edit page.

And I'd be mildly surprised if any of the parsers in current browsers
do even string sharing. Parsing the same string (e.g. URL or ID)
twenty times will probably create twenty identical string objects,
while parsing a JSON expression and copying the string reference will
spawn a single object. This may not seem much in and of itself, but I
rarely work on a single page (partly because of the loading times),
and I often have many other big pages displayed when working on MB
(artist's pages, cover sites, several Google searches, any relevant
catalogs, and whatever else I might be multitasking on), and running
other programs than my browser.

Of course, brianfreud's suggestion might not help with all that—it
needs tested to see if it's really faster—but it shouldn't be
dismissed indefinitely.

-- Bogdan Butnaru

PS. On the several occasions I've looked, the MB HTML was illegible to
my unaided eyes. Adding a bit more structure and removing some
redundancy might help.


On Mon, Jul 20, 2009 at 10:07 PM, Kuno Woudt <kuno@...> wrote:

> 21:13 < brianfreud_> In an inlined editor, my concept is that editing takes place in a js-modified (js loaded on demand, so no pageweight++) version of the page.
> 21:13 < brianfreud_> But that means either js making the form fields, or the server *always* including them.
> 21:14 < brianfreud_> The latter doesn't make much sense to me.
> 21:14 < aCiD2> When I wrote the artist credit editor, I found it much easier for the server to spew out all the required fields, and the JS to just move the around as it needed to
> 21:14 < brianfreud_> The negative, then, is that, when we want to pass data into editing forms (url args, etc) from the server, we have to get that data from the server into js.
> 21:14 < brianfreud_> aCiD2: easier, but it bloats the pages, every single time, a good deal
> 21:15 <@ruaok> I think emitting a few fields to support editing isn't that big a deal. compared to all the tables we used to use it should be a small amount of data, no?
> 21:15 < brianfreud_> we're dealing with very redundant HTML snippets; easy to insert them only as needed.
> 21:15 < brianfreud_> no
> 21:15 < brianfreud_> you'd prob be looking at doubling the size of every single page

[...]

> 21:15 < luks> note that it's not every single page
> 21:15 < brianfreud_> how is inserting into div Foo 1..n copies of the same HTML "wierd JS"?
> 21:15 < luks> it's every edit page and I'm happy with that
> 21:16  * ruaok is with luks
> 21:16 < brianfreud_> every page is an edit page...
> 21:16 < aCiD2> brianfreud_: because you're having a problem with how to get data into them, when HTTP just does it for you? :)
> 21:16 < aCiD2> When we go live, we're going to have forward proxies, data compression and all sorts of other fancy stuff that makes a few extra bytes in some static html much less of an issue
> 21:16 < brianfreud_> aCiD2: my thought was, when we do need to pass data, just have the server include into the page a js / json array, for js to then parse and populate into the fields
> 21:17 <@ruaok> that seems silly to me.
> 21:17 < aCiD2> I'm going to have vote -1 on that until I see a more conventional way not working
> 21:17 <@ruaok> I think the gzip compression is going to be more effective and our code remains simpler.
> 21:17 < brianfreud_> aCiD2: it just doesn't make a lot of sense to me to always be including a bunch of hidden fields (1 for each artist, 1 for each track title, one for each label, each cat #, each everything...)
> 21:17 < aCiD2> sure it does
> 21:18 < aCiD2> it's a field, you include the field, makes sense to me
> 21:18 < brianfreud_> well, I can do it either way.
> 21:18 < brianfreud_> But I think the way I'm describing makes a lot more sense.
> 21:18 < aCiD2> It violates luks' mantra of do the simplest thing
> 21:18 <@ruaok> and consider the fact that the edit pages don't constitute a large amount of our bandwidth... the WS does.

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Robert Kaye]

On Sep 14, 2009, at 9:39 AM, Bogdan Butnaru wrote:

> Did anyone consider that it's hurting some users?


Yes, we have in great detail. We have and are considering all of the  
issues you've raised -- have you played with NGS on the test server  
( test.musicbrainz.org )? You should take a look at the HTML generated  
and general speed of things on that server -- I think you'll find that  
we've already addressed most things you're talking about.

Our main objections to Brian are that Brian wants to make "the most  
efficient editor possible", which is a nice goal. But we refuse to  
have a super efficient editor that we can't maintain because the speed  
features make it too complex. The types of optimizations that Brian  
are talking about will in the end eek out a few percent of speedup  
that won't really be noticeable to the end user. And the end user  
won't care because we're going from something slow and awkward to  
something sleek and sexy. I predict that no-one is going to clamber  
for the extra few percent we're talking about here.

--

--ruaok      "Vague, but exciting..." -- Mike Sendall on the WWW  
proposal.

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net






_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[bogdanb]

OK, great then. I have been out of MB for a month or so, and I didn't
follow all discussions in that time.

I took a look at the test server, and at least from what I saw it was
sexy* and fast. I couldn't figure out how to edit or add a release, to
compare—is my login there is not allowed to edit, or isn't the editor
on yet?

-- Bogdan Butnaru

*: It's a bit too slender for my eyes, though. I'm annoyed by pages
with a fixed horizontal width; was that a conscious decision? I have a
wide-screen monitor, and although Firefox's zoom works quite well for
text itself, I don't like scaling the whole page (because of image
pixelation). It's annoying to have titles wrap in table columns, while
having a 20%-wide slab of my screen empty on each side.



On Mon, Sep 14, 2009 at 7:40 PM, Robert Kaye <rob@...> wrote:

> On Sep 14, 2009, at 9:39 AM, Bogdan Butnaru wrote:
>> Did anyone consider that it's hurting some users?
>
>
> Yes, we have in great detail. We have and are considering all of the
> issues you've raised -- have you played with NGS on the test server
> ( test.musicbrainz.org )? You should take a look at the HTML generated
> and general speed of things on that server -- I think you'll find that
> we've already addressed most things you're talking about.
>
> Our main objections to Brian are that Brian wants to make "the most
> efficient editor possible", which is a nice goal. But we refuse to
> have a super efficient editor that we can't maintain because the speed
> features make it too complex. The types of optimizations that Brian
> are talking about will in the end eek out a few percent of speedup
> that won't really be noticeable to the end user. And the end user
> won't care because we're going from something slow and awkward to
> something sleek and sexy. I predict that no-one is going to clamber
> for the extra few percent we're talking about here.

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

On Mon, Sep 14, 2009 at 8:31 PM, Bogdan Butnaru <bogdanb@...> wrote:
> I couldn't figure out how to edit or add a release, to
> compare—is my login there is not allowed to edit, or isn't the editor
> on yet?

You just found one reason why such premature optimizations are bad. :)
They don't go well with getting things done.

--
Lukas Lalinsky
lalinsky@...

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel