Baker Linden gave us another update on how he is coming along with fixing group editing. There is hope but there are some issues to be solved too.
Baker said, “I’m in the middle of debugging the server code.
For announcements, I’m pushing legacy viewer support to the back burner. The new group data format is similar enough that some things should show up in the group list (I haven’t tested that yet), but not everything [will show up] ([i.e.,] currently group roles, and potentially other pieces of information).
I could also be lying to myself about that as well; it may be totally incompatible — I’ll have to wait and find out when I get to the viewer side of this. This is why I’m pulling it off the list — if it works, fantastic; if it doesn’t, then it doesn’t.
I think it’s not worth the time spent to support legacy viewers; I’d rather ship the fix, allow TPV to support the new format and allow people to actually use this feature. It’s just a matter of reformatting the data, but that extra work means more time spent on it and not delivering the feature.
I doubt it’s going to be that big of an issue.”
Remember. He is new.
Simon Linden suggests, “We might leave the old code in, Baker, and just use different paths depending on the viewer support.”
So, we are getting information way early in a fix process, far more so than we usually do. It will be interesting to see how the community treats Baker when something has to change.
Baker went on to say, “Well, the old code will not work, so it’s the same thing, except for smaller groups.”
Simon responded, “Yeah, maybe put a sane limit on the old one so it stops hurting the back-end systems.”
Baker, “I mean, the old code will still be there in the event that a legacy viewer is managing a group < ~12k people, but that’s it. I mean, it really is just reformatting the data before I send it through the pipe, but it will also inflate the data to (what I consider) an unreasonable size for UDP.”
Summary
Work is proceeding on fixing the group editing for large groups. I think Baker is early in the process and that we are weeks away from seeing this reach a place where we can use it.
I am happy to see him not being held back by legacy viewer compatibility. But, this will mean legacy viewers are not going to be useful for groups in the 12k range and above.
He also seems to be sticking with UDP. I’m not sure that is the best idea, but it probably is the faster fix.
We’ll hear more on Friday. Hopefully it works as he hopes.
Sounds like Baker has the right idea. Fix the problem clean up the code and make it work for todays viewer. this is 100% how this should be done. I am happy to see all these updates so early in the process, but i hope that the inevitable complaints about this dont derail Bakers plans.
Surely the choice between UDP and HTTP should be distinct from the data format. I can see the system being UDP now, and HTTP later. That is the general plan, after all.
Is that just me? But even groups around 10.000 members do not load for me in the viewers 3.3.3. and newer. Well, they load, but it takes tons of time with occasional crashes. I was told it is because of VWR-29124. So, if Baker implements his fix, the large groups will still not load. Or is that just me who has this problem? Can you find out anything about this, Nalates?
Right now the problem is all the viewers attempting to load group lists jamming up the server. With Baker’s fix older viewers will likely be limited to <=12k groups. Newer viewers will use the new data format to handle >12k groups.