javaBin/ems-redux

Permalinks

chrissearle opened this issue · 13 comments

Apps need permalinks to make sharing/social media meaningful.

It would be best for the apps that this data was available as links with a "permalink" rel in the C+J document for sessions.

+1 on this. Can we get it? It will also be crucial to support search and deep linking in iOS 9.

Then someone need to let us know the rules for generating the correct uris. @Espenhh or @sveinung should know this

And maybe @bendiksolheim

As written here (javaBin/ems-ios@d71dbe7#commitcomment-12101648), doing this for all years of sessions is a bit difficult. Maybe we could start with adding this for 2015-sessions? (and maybe 2014 and 2013 as well, the scheme is quite similar) One of the nice things about links is that they "can be missing", so the app should be able to handle some sessions with links and some without.

The "ID's" for the last three years are created by doing hex(sha256(ems-link)). The URL-patterns are:

This is the code that generates the IDs:
https://github.com/javaBin/javazone-web-api/blob/master/src/main/java/no/javazone/ems/ItemMappers.java#L28
(this is the code for the 2015 API, but it is as far as I can see copied from the 2014/2013 code)

Great. thanks.

what about the test server? is that only operational for 2015?

http://test.2014.javazone.no is now up again. For 2013, I will have to figure out how to log into the server, quite an old setup (before ansible).

BTW: the test-servers are connected to prod-EMS. Let me know if that's an issue, and I can look into eg. making the 2014 one go against test-EMS :)
(going on holiday trip today, so let me know before 16.00, if not it will have to wait until wednesday)

Would it make things easier if we try to standardize things a bit? I guess we could quite easily change this years URL to be the same as last years URL, with the year as the only difference.

2013-2015 would be a great start:)

  1. jul. 2015 kl. 11.25 skrev Espen Herseth Halvorsen notifications@github.com:

As written here (javaBin/ems-ios@d71dbe7#commitcomment-12101648 javaBin/ems-ios@d71dbe7#commitcomment-12101648), doing this for all years of sessions is a bit difficult. Maybe we could start with adding this for 2015-sessions? (and maybe 2014 and 2013 as well, the scheme is quite similar) One of the nice things about links is that they "can be missing", so the app should be able to handle some sessions with links and some without.

The "ID's" for the last three years are created by doing hex(sha256(ems-link)). The URL-patterns are:

http://2015.javazone.no/details.html?talk= http://2015.javazone.no/details.html?talk= (can't be shortened)
http://2014.javazone.no/presentation.html?id= http://2014.javazone.no/presentation.html?id= (can be shortened, quite similar to how GIT SHA works. But full length works as well)
http://jz13.java.no/presentation.html?id= http://jz13.java.no/presentation.html?id= (can be shortened, quite similar to how GIT SHA works. But full length works as well)
See this for the code that does the ID generating:
https://github.com/javaBin/javazone-web-api/blob/master/src/main/java/no/javazone/ems/ItemMappers.java#L28 https://github.com/javaBin/javazone-web-api/blob/master/src/main/java/no/javazone/ems/ItemMappers.java#L28
(this is the code for the 2015 API, but it is as far as I can see copied from the 2014/2013 code)


Reply to this email directly or view it on GitHub #21 (comment).

Agreed. Sharing is most likely only relevant for 2015 and future. But for deeplink/search the more the better - but we don't have to have everything from day 1 ;)

Right now, the program sites before 2013 is "borked" on the web. It happened when we switched servers. We have a backup, but haven't had the time to fix it yet. So 2013-2015 is the only viable option at this time anyways... :P

Regarding deep-linking. My takeaway from WWDC 2015 is that custom url schemes is going away in the future from iOS. So if we want to make a today extension, for instance, we absolutely have to use permalinks to be able to communicate with host app. That does not necessarily mean that we need those urls to actually be valid on the web, but it would certainly make the experience better.

Commit aa21513 should fix this.