Issue 171 rev1 (team 4)

[agiz]

Location API #171
HTML5 location #172

[mitar]

Please update to new code from main repository.

As described in #171, there is a placeholder for this code.

[mitar]

Just to make sure, I am waiting for you here, no?

[agiz]

Am I not sure? Was not this closed with 957d056 and aa1ffd6?

[mitar]

Yes, #171 is done. But #172 is not yet.

[agiz]

Modify this to return assigned node?

[mitar]

Hm, no. We will use HTML5 geolocation to send this information to the server, which will then based on that find closest node and then other parts of the portal will work as expected. So this should be done only on /outside/ view.

[agiz]

What and how shall we do (things) here?

[mitar]

Check /outside/ view. And check how our code finds closest node. It reads some information from session. So we will use HTML5 to get this information and store it into session. Then we will be able to find closest node.

[agiz]

Is this the only way how to assign node to a user? If I understand things correctly there is some other mechanism (not part of piplmesh) that assigns node to user if user is connected on internet through that node.

[mitar]

Don't forget to update this from main repository before you start working. Currently it is not.

You never assign node to the user manually. This is done by out nodes API. You just provide API with additional data (latitude and longitude), so that it can fallback to search for closest node if user is not connected directly to the node.

Currently, for development, we just pick node at random. In reality, we will use user's IP to see if it is internal IP and from which node, or not. And in the later case we will search for closest node.

[agiz]

I get this. I will try to be more careful with wording. What is unclear is do we send HTML5 geolocation regardless if it is already known what node is user assigned to? The script I wrote only sends HTML5 data if user is not connected on internet via node.

Scenarios:

1. User is connected directly to the node. Nothing else shall be done.
2. User is not connected directly to the node. User sends HTML5 geo data, server responds with node.

[agiz]

I saw outside code. I can implement it the way it is imagined. Would not it be better if location gets sent without user interaction?

[mitar]

I would do it like that:

• if user is connected to the node, then we do nothing, we have location
• if user is not connected to the node, then we redirect her to outside, where she is asked to allow us to get her geolocation through browser (/outside/ view), if she confirms
• we retrieve location, save it to session and redirect to home
  (* we could regularly (probably simple on page load for now) check geolocation and update it in session; but that we can do later, when we will also have logic what happens, when user moves from one node to another)

Can you determine if we are allowed to use geolocation without triggering permission check popup?

So scenario 2. above is: user is not connected to the node, there is nothing in session, so she is redirected to /outside/ where she confirm geolocation, this is send to the server, and she is redirected to home, there request.node is normally populated by our API.

So server does not respond with anything when sending it geolocation, simply redirects to home. Later on we could use that to update the node, if user moved to new node.

[agiz]

The answer to the first question is no. That is why I asked, because this way, user is asked to confirm (practically) same thing twice. Location permission however gets stored in local storage I think so she will not get bothered once she sets allow geolocation + remember. That said, this is per-browser setting.

Is it important that user is redirected to outside? And what happens when she chooses do not allow? And as you said it yourself, what happens when user moves away from node 1, closer to node 2.

My vision of scenarion 2: User is notified that she is assigned to the closest node. No redirections, no confirmations beyond necessary ones.

By respond I meant probably the same as you - server sets nearest node.

[mitar]

Yes, redirecting to /outside/ is good because it is also easier to implement. Then you have only one point of entry and simply forbid anything else. On a HTTP level, not somewhere in JavaScript. Also you can explain to the user why is she asked the question (but OK, this could be done also in JavaScript pop-up/layer or something).

I don't understand why would user confirm same thing twice? There would be only one confirmation (at /outside/). Or it is per-URL? Is not per-site?

If she chooses to not allow, she stays at /outside/. ;-) Later on we will implement a concept of home node. This is the node you assign yourself as home (at one moment you are connected to it, for example, only once a month you are allowed to do that). And then you will be able to say that you want "home node" view of the portal if you will be connected from outside. This is for example, if you will not be interested in geo-based information, but just wanted to access what you neighbors and others are talking about, but you are not at home/in the network. So in fact /outside/ will later on give you two options: use HTML5 geolocation, or use "home node" view. For now, we simply leave user "outside".

Moving between nodes is a problem on itself and will be solved some other time (after 1.0).

The problem of your scenario 2: once request comes in and you discover that it is not from user connected to any node in the network, you do not have time anymore to request HTML5 geolocation. And you simply cannot find closest node. So you have to do something: you redirect to the site where you request this.

Look at this similar to how Facebook is if you are not logged in. Open it, you will see, it is empty. ;-)

[agiz]

Hmmm... I would discuss this further on wednesday but you are absent. Yes, confirmation is per-site. HTML 5 geolocation cannot be resolved at HTTP level as it requires callback. Will reread and reconsider your thought tomorrow.

[mitar]

I will be on Wednesday, so we can discuss it in person.

[mitar]

Ping. Please finish. Update from the main repository, too.