Support for pages

[tzafrir]

When a page interacts with Google+, all request appear to be the same, just with a '/u/0/b/${PAGE_ID}/' instead of '/u/0/'

How should this be modeled in the API?

Maybe a parameter in the constructor?

[mohamedmansour]

Pages is a complex thing, we need to extend the data layer so there could be pages support since that data is only for a single user.

We need another table that states "accounts" where it has three columns "id, googleid, pagesid" Then we need to somehow map each session to its corresponding googleid (not hard already have the api call there), then we construct the prefix for each URL.

As a developer who uses the API, how will they switch between pages and accounts? For accounts, it might seem simpler by just adding it to the constructor (googleid), but for pages, it would need another public method: (dunno naming structure yet).

1. getPages
2. setPage

The getPages, should return a list of pages (there must be some RESTful API that Google uses that does that. And the setPage would basically change the prefix of each request to what you specified.

I would rather model the constructor to be the GOOGLE_ID (Current logged in session), and managing the PAGE_ID within the class which requires two new methods.

Since today is Friday, let me see what I can do wrt to that after work. It is going to be difficult because we need to figure out when a user signs out/switches user/switches pages. Because we need to make sure the current session is tracked within a variable so the other requests could use it.

[tzafrir]

The list of your pages come from https://plus.google.com/u/0/_/pages/getidentities/

Isn't it simpler to have a full copy of the API for each identity? They each have their own people in circles, profile, etc.

[mohamedmansour]

I have used /pages/get instead because /pages/getindenties returned an extra page which is your profile. Less parsing for me to do.

Committed here b6d2941

Now I need to figure out a proper way fixing the localStorage because we don't want to mix up data persistence from other accounts.

[tzafrir]

What's the current status of pages support?

[tzafrir]

@mohamedmansour I'd like to work on this issue, can you brief me on how you planned to approach this and how I can continue this work?

[mohamedmansour]

Hey @tzafrir , my original approach was mimicking what Django has for "sites" when you create a project. Instead of "sites" it could be "pages". The reason this is needed is because we are dependent on the Web SQL store (I don't know if we still want that, but it makes querying a lot faster). So perhaps we should have a user store, a user would have access to some "page" and then that page id would be referenced in all the other tables.

So right now every entity is implementing AbstractEntity, we could make that step further and define each entity to have a "page" column. Then we will have another table that tells the user what pages is currently persisting. We could create a user management so the user can easily unlink a certain page (all data would be removed).

Each Service REquest has a page token and that would be set from the setPage I believe. I believe that would be better than forcing the coupling to be based on the currently logged in user. The consumer of the API (doshare) could select a page from a dropdown and use that, they don't have to be logged in or anything. But the developer should specify the page id, if it isn't, then it will use the primary one.

So what needs to be done:

1. Extend all the entites to have a "page_id" column.
2. When persisting entities, we need to get the current assigned page_id and store it in every call.