These are chat archives for abranson/rockpool

28th
May 2016
Andrew Branson
@abranson
May 28 2016 09:33
that should be all the tokens afaik. user == account. the only reason for the timeline token's existence is to anonymise the user between apps.
AppResMap: could it be purely in SailfishPlatform do you think?
ruff
@rufferson
May 28 2016 09:45
I think it would be useful keeping it cross-platform - hence I moved it to platform interface. Eg. it's still definitely platform part, however keeping it common across platforms allows having common look&feel for platform notifications across various platforms
Andrew Branson
@abranson
May 28 2016 12:43
I understand that, but there's really nothing in there except for the AppResMap itself; all the logic is in the sailfish platform.
ruff
@rufferson
May 28 2016 12:51
Yes, my idea was later to make a blind port of the ubuntuplatform to json pins (using that resmap). as ubuntu platform is apparently broken now, and if we move resmap to sailfish platform - we can just drop ubuntu and forget about it :)
Andrew Branson
@abranson
May 28 2016 12:52
Hmm I'd like to think we can reintegrate with that at some point :)
ruff
@rufferson
May 28 2016 12:52
exactly my hope
Andrew Branson
@abranson
May 28 2016 12:54
I think the appresmap would integrate quite nicely into that timelinepin subclass I mentioned before. Then we could define a basic set of notif types in core, and let the platform add to them, and the type is taken as a constructor parameter.
But I think that's not a short-term goal
ruff
@rufferson
May 28 2016 12:56
I'm now stuck in indecision whether to keep all the api at timeline manager class, or distribute them across major consumers. Eg. those jskit.pebble.getTimelineToken - apparently it's jskit only call, no one else would need timeline token. however urls are similar to those in timeline websync, and it needs oauth token which is currently also kept in timeline...
then there's this locker interface. It makes sense to move it to appmanager class. however again the only beneficiary of it will be - again jskit
and again it needs oauth
so trying to make up my mind on how to make it in most optimal way, with max code reuse and min repetition
Andrew Branson
@abranson
May 28 2016 12:58
those tokens are quite central I think. the methods to fetch them for JS apps are in the JS kit, but the authentication should also be used by the store client and who knows what else in the future
the timeline subscription fetching isn't jskit either
it could even be a new manager
ruff
@rufferson
May 28 2016 12:59
no, timeline works with single url - timeline-sync.getpebble.com all the derivatives are sent as part of the feed from this url
Andrew Branson
@abranson
May 28 2016 12:59
but it needs to identify the user/watch?
ruff
@rufferson
May 28 2016 13:00
locker api is part of api2.getpebble.com - which is used by appstoreclient in the client part
Andrew Branson
@abranson
May 28 2016 13:00
maybe all communications with pebble.com should be handled in one manager
and these other components talk to that, and that's what holds the oauth and tokens
when should a user log in? there's a strong requirement from users that logging into pebble should be optional. they like the anonymous usage of the store right now
ruff
@rufferson
May 28 2016 13:01
there's no point to keep any other token rather than oauth
because it will be a mess the clean them up if user decides to logout or change account
Andrew Branson
@abranson
May 28 2016 13:02
not persistently
but methods like JSKitPebble::getAccountToken shouldn't fetch it themselves
ruff
@rufferson
May 28 2016 13:03
even without persistence. Eg. in jskit i store it in jskitpebble class member, so when app stops - token disappears. but till it runs - token is fetched just once
bcz again - token is app sepcific
Andrew Branson
@abranson
May 28 2016 13:03
even accountToken?
the timeline tokens are app specific yes
ruff
@rufferson
May 28 2016 13:04
yea account token could be coupled with oauth token and stored together
Andrew Branson
@abranson
May 28 2016 13:04
but it probably should still be up to whichever object holds the oauth to be handing out timeline tokens to apps
ruff
@rufferson
May 28 2016 13:04
those could really be preserved and always kept in sync
Andrew Branson
@abranson
May 28 2016 13:04
the oauth token shouldn't really be public in the application. it can be encapsulated.
ruff
@rufferson
May 28 2016 13:05
so that the thing. the way i did it now - is that timelinemanager is a key-keeper. it owns oauth and authes all the api calls by injecting oauth into the calls
Andrew Branson
@abranson
May 28 2016 13:05
yeah that sort of thing
but seeing as other component like the store might be wanting to use it, it could be factored out do you think?
ruff
@rufferson
May 28 2016 13:06
the tricky part is that locker api, it just doesn't match to this nice isloated world of pins and tokens
it's really app-manager specific, but still needs oauth to functioning. mb just make some kind of TimelineManager::authRequest(QNetworkRequest *req) to pass through timeline for authentication before going for own needs...
Andrew Branson
@abranson
May 28 2016 13:09
the locker is where you get each app's timeline token from?
ruff
@rufferson
May 28 2016 13:09
yes, the thing is we don't realy need it for anything else
Andrew Branson
@abranson
May 28 2016 13:09
using the store id?
ruff
@rufferson
May 28 2016 13:09
uuid
it just allows as a side effect to fetch storeId of the app by the UUID. otherwise there's no other way to do it
but again - we don't really need it
it works fine as is
potential usage for it is to keep apps common across andorid/ios/jolla
so we add all installed apps to locker. and similarly when user log in we check the locker and automatically install what we miss, and register what it misses
Andrew Branson
@abranson
May 28 2016 13:12
but for each app, JSKitPebble::getTimelineToken has to return that for subscription purposes?
and timelineSubscribe needs to use it too?
ruff
@rufferson
May 28 2016 13:13
yes. the way it works is - timelinemanager jsut sits on the feed and waits for pins. pins should be pushed by something. for something to start pushing pins for you you need to subscribe, for that you need a) timeline token (your anonymous identity) and topic
Andrew Branson
@abranson
May 28 2016 13:17
as i understand it, pins get pushed from their central source from pebble after you've subscribed.
ruff
@rufferson
May 28 2016 13:17
so when you install timeline-enabled app it gets your timeline token from jskit.pebble object and suggests you topics to subscribe. you select topics - and it sends subscription request to pebble. AND! your timeline token to itself (own server). pebble then selects based on your topics what to insert into your feed. while own server just adds your timeline token to the sent pins (for all topics)
Andrew Branson
@abranson
May 28 2016 13:17
so the subscription is independent from the actual pin pushing
ruff
@rufferson
May 28 2016 13:18
yes, subscription is kind of filtering
Andrew Branson
@abranson
May 28 2016 13:18
yep
ruff
@rufferson
May 28 2016 13:18
rather whitelisting
Andrew Branson
@abranson
May 28 2016 13:18
i remember in the other pebbled chat, javispedro was a little disgusted that all app pins had to go through pebble.
ruff
@rufferson
May 28 2016 13:19
if you want them delivered via websync
on jolla we are not limited by that
we can insert them as we want
Andrew Branson
@abranson
May 28 2016 13:19
no, but officially it's the only way for a jsapp to create pins
ruff
@rufferson
May 28 2016 13:19
yes
Andrew Branson
@abranson
May 28 2016 13:20
nearly got it all sorted here - for some reason my firmware update notification is being rejected for not having a parent defined in the pin
ruff
@rufferson
May 28 2016 13:22
empty owner?
Andrew Branson
@abranson
May 28 2016 13:22
second part of dataSource?
ruff
@rufferson
May 28 2016 13:24
just thinking why it could be missed. there's dataSource field reassembly in Pebble::insertPin before fitlering happens. that is to remove colons in first part. but still, if owner is empty, datasource will be ":0000-0-0-000" which after split should still give 2 elements, just first will be empty..
second part is always pre-set with that hardcoded uuid you've found - data_source_sys_notification or whatever
Andrew Branson
@abranson
May 28 2016 13:26
i was creating the notification with sendSimpleNotification
ruff
@rufferson
May 28 2016 13:26
ah, pebble firmware
so that one needs app uuid
Andrew Branson
@abranson
May 28 2016 13:27
with a zero uuid, so "dataSource": "00000000-0000-0000-0000-000000000000:00000000-0000-0000-0000-000000000000"
ruff
@rufferson
May 28 2016 13:27
zero is invalid
Andrew Branson
@abranson
May 28 2016 13:27
i see
i'll make a random one then
thx!
ruff
@rufferson
May 28 2016 13:28
yea, for notifications random is ok, notifications aren't supposed to be updated, just re-inserted if required
Andrew Branson
@abranson
May 28 2016 13:28
yep
I thought it would be good to actually alert you when there's a new firmware. there's a 'systemMessage' sent to the pebble, but katharine confirmed that it doesn't actually do anything...
ruff
@rufferson
May 28 2016 13:30
supposedly sysMessage should update settings tab with new version available. but no one looking there so they probably didn't bother connecting it
Andrew Branson
@abranson
May 28 2016 13:31
i think some of the other ones work, like SystemMessageFirmwareStart and SystemMessageFirmwareComplete. But SystemMessageFirmwareAvailable does nothing.
But I think on the android app they send a plain notification like this
ruff
@rufferson
May 28 2016 13:51
Don't do random - it wll generate new notification sources in filter
use SETTINGS_APP_UUID
Andrew Branson
@abranson
May 28 2016 14:03
Oh it's ok, it wasn't using that for the filter anyway
It nicely appears in the filter as 'Pebble Firmware Update'
ruff
@rufferson
May 28 2016 14:28
prob. your modified version, mine apparently uses UUID as a sourceId so would generate a filter per each call with random UUID
Andrew Branson
@abranson
May 28 2016 18:54
Hmm now I'm regretting that. Yours works quite well for identifying the watchapps from the js call, and I'm not sure the Pebble.sendSimpleNotification is needed at all. I could do a custom one for the firmware, and move that logic completely to JSKit
ruff
@rufferson
May 28 2016 18:56
I'd not bother creating call for one task, formatting json document is not that hard, mandatory is dataSource, id and layout with title and body and type. the reset will be added by insertPin in the pebble
Andrew Branson
@abranson
May 28 2016 18:57
yep
i'll drop Pebble.sendSimpleNotification, and just connect JSKitManager::appNotification directly to insertPin
ruff
@rufferson
May 28 2016 19:00
btw need to get rid of manadatort type=notification for the pin, timelineManager user pin's type or falls back to layout's type (if pin is not explicitly set). so just need to add that fallback to type check for filtering. pin type could then be used for some corner cases (like notification type with reminder layout)
Andrew Branson
@abranson
May 28 2016 19:00
sounds good
Andrew Branson
@abranson
May 28 2016 20:48
just pushed my minor changes. going to test all this out over the next few days. I called it 1.0-alpha1 :)
ruff
@rufferson
May 28 2016 21:11
btw layout type better to keep as per pebble SDK. that one is parsed according to layouts.json file and is set as pin param. while pin's type is internal only used just to sort them out and categorize during pre-processing. That's where I'm saying that current TimelinePin class is using that pin type if it is defined but otherwise falls back to layout type based on hardcoded conversion matrix (name2type). But serialization makes no assumptions and just skips setLayout step when type is not parsable.
For this particular purpose it's not really affecting anything as generic layout covers simple notification requirements. but just to keep in mind.
That's related to firmware notification where you put layout.type=notification. should be genericNotification or commNotification