On Tue, Mar 10, 2015 at 11:30 PM, Dan Garry dgarry@wikimedia.org wrote:
On 10 March 2015 at 10:33, Bernd Sitzmann bernd@wikimedia.org wrote:
A few questions for you:
- Is (a) enough for https://phabricator.wikimedia.org/T91794?
No. One of the primary objectives for doing this is so that we see what the pain points are of actually deploying this to production, to decide whether to make a further investment into the service. Deploying it to Beta Labs doesn't meet this objective at all.
+1.
So IMO the thing you are actually testing is the *process* of getting this into production, not the software itself. Putting it in beta is part of the process of getting it into production, but as such is useless if it stops there. Beta is just a place to test the software itself, and the most risky thing here is not the software itself, but ops/tech-community/core acceptance of doing things like this. Only getting it to production will help shake it out, for you and other teams that follow in your wake :)
There's a lot of unknowns along that path, so good luck :)
On Wednesday, March 11, 2015, Yuvi Panda yuvipanda@wikimedia.org wrote:
IMO the thing you are actually testing is the *process* of getting this into production, not the software itself. [...] Only getting it to production will help shake it out, for you and other teams that follow in your wake :)
Exactly! :-)
At this stage the required improvements to the service itself are relatively clear with few unknowns. However, the deployment of the service to production, even as an experimental service, has a lot of unknowns.
Let's keep our eyes on this goal.
Dan
Thank you for the feedback. It's clear that we need option (b) but at a reduced scale initially, and later when we want to actually use it for the beta app increase it, then later for production increase it some more.
This helps with estimating the task https://phabricator.wikimedia.org/T91794 for next sprint.
Marko, about your other question. I think the service will change some more in the future, and could change quite substantially. It's just not sure when exactly but still while having it marked as experimental.
Monte and I are playing with the idea of changing the format and Content type from JSON with embedded HTML to HTML with some metadata embedded as JSON. The embedding could be done multiple ways, probably inside the HTML in a JS script block (<script> tag). (Alternative options could be also CDATA blocks or even multipart.) I'm thinking we could have a small portion of metadata at the beginning of the payload for performance reasons to include whatever is needed to display above the fold: page id, rev id, title, description, lead image url, .... And then we'd have another section of metadata (ToC, gallery, read next, ...) at the end of the payload. The idea for the client would be to instead of sending each section HTML over the JS bridge to just use WebView.loadUrl() <http://developer.android.com/reference/android/webkit/WebView.html#loadUrl(j..., java.util.Map<java.lang.String, java.lang.String>)> and take advantage of streaming that way. This would significantly reduce the number of requests. This would also reduce the payload since we don't have to encode HTML inside JSON. Well, that's the current idea. We'll see how this would work. I think the service could be easily change to do that. This would be a bigger change on the client side, but should make client code simpler and much more performant, too.
Cheers, Bernd
On Wed, Mar 11, 2015 at 9:47 AM, Dan Garry dgarry@wikimedia.org wrote:
On Wednesday, March 11, 2015, Yuvi Panda yuvipanda@wikimedia.org wrote:
IMO the thing you are actually testing is the *process* of getting this into production, not the software itself. [...] Only getting it to production will help shake it out, for you and other teams that follow in your wake :)
Exactly! :-)
At this stage the required improvements to the service itself are relatively clear with few unknowns. However, the deployment of the service to production, even as an experimental service, has a lot of unknowns.
Let's keep our eyes on this goal.
Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation