HTML5App looking for "POST /tunnel"

[gvaish]

Wonder if HTML5App should look for "/tunnel" even if there are no components with any server affinity?

[caridy]

Can you elaborate more? Tunnel will not work with an offline app.

[gvaish]

@caridy Bingo. I assumed/expected the same :-)

Basically, what I was looking at is - if I have mojits that have either common or client affinity controllers only, can Mojito work without making a call to "/tunnel" to fetch the components (views, model, controller etc).

I guess it doesn't make too much sense for this case...

[gvaish]

Well, the "referenced issue" is - tastejs/todomvc#507

[caridy]

I'm not so sure I follow. Views, Models and Controllers are just YUI modules setting in the static folder when producing an offline app. They will be loaded when needed without any hazard. Aside from that, the definition/spec will be loaded from local as well since they will be precomputed and stored in disk. In other words, on demand mojits will/should work just fine. What will not work is the mojitProxy.invoke() if a component is a server side.

[gvaish]

@caridy The issue that I am seeing is that even though all components have "common" affinity (controller + model), the html5app code generated makes a call to /tunnel.

btw, the application is live at http://gvaish.github.com/todomvc-mojito/common/
Keep the firebug open and you'll notice two calls:

1. /static/TodoMojit/definition.json?runtime=client&site=&device=&lang=en&langs=en%2Cen&region=&jurisdiction=&bucket=&flavor=&tz= -- this should have been /common/static/... -- wondering if this should be with query-params or .../definition.json only
2. /tunnel -- why? Do I have a wrong config at https://github.com/gvaish/todomvc-mojito/blob/master/todomvc-mojito-common/application.json ?

Adding @isao

[caridy]

@gvaish few comments:

• /static/TodoMojit/definition.json?*** is just fine. Those querystring parameters will not play a role because that definition.json was already generated when you did mojito build html5app path/ --context whatver:something, so, they will be effectively ignored.
• /tunnel calls should not be made under those conditions unless that a particular mojit is forcing controller to use server affinity.
• If a call for definition.json fails, that's an indication that the mojit cannot run in the client side and the tunnel will be issued, and apparently that's what is going on here, because http://gvaish.github.com/static/TodoMojit/definition.json returns 404 for whatever reason.
• this seems to be a problem with the relative path that has to be used in your app, if you hit this url for defintion: http://gvaish.github.com/todomvc-mojito/common/static/TodoMojit/definition.json?runtime=client&site=&device=&lang=en&langs=en%2Cen&region=&jurisdiction=&bucket=&flavor=&tz=, it works just fine. I will try to reproduce the issue later today.

[caridy]

@gvaish I was able to reproduce the issue, and I found a couple of bugs in store-client that prevent the use of relative paths in HTML5 apps, I plan to fix it asap. I will commit against this issue.

[caridy]

Trello card: https://trello.com/card/todomvc-gh1050-store-client-does-not-play-nicely-with-relative-static-handling-prefix/504e5e3b7cd1578456fc430f/474

[gvaish]

@caridy Cool. So, it seems the todomvc app has really served Mojito dev well 😄

Will await the updates. Take your time!

[gvaish]

@caridy Is the Trello task done? I saw a notification

Jenny Donnelly checked Add missing tests to IDE integration suite [IDE no longer supported] on
[todomvc][gh1050] store-client does not play nicely with relative static handling prefix on mojito-dev

But then the card went missing... Got curious.

[caridy]

@gvaish we discussed the card today during a meeting, and we have decided to move it into another board where we are reworking mojito-next which is the next big iteration on mojito and its underlaying components. The reason why we moved there is because I have found some issues with the current implementation and fixing it might take longer that I was expecting which aligns better with the refactors that we are planing for mojito-next. In other words, this might get ready in 0.6.x but not in 0.5.x. Apologies for the inconveniences, and I will recommend you not to load dynamic mojits when running and html5 ap in the meantime. We can discuss more offline.

[gvaish]

@caridy Will ping you directly.