There are a lot of painful implications to how requestNavigateTo works
within OpenSocial that should be addressed asap. Failure to fix these
issues will hinder developers and business models on the platform.
Here is my suggestion.
Currently applications emit at the server or rewrite on the client
simple links into complicated javascript calls. For us in iLike,
instead of generating:
Going through container javascript to navigate isn't the worst thing
in the world, but the fact that there is no real URL in the browser
has several perhaps non-obvious implications to the user experience,
business model, and technical layering which are worth thinking about
and fixing:
1) when links are real HREF's in the browser, users can see where
they are going when they hover over things, and they can copy/paste
links and send them to friends. They can DIGG them, they can post them
to facebook, they can copy them into google bookmarks. They can save
them in their browser favorites. They can open links in new tabs. They
can do none of these things in opensocial containers right now.
2) Links to canvas pages from activity stream items and any kind of
container notifications are also not going to work trivially -- gadget
javascript is not involved, we need to embed specific links into
activity streams, notifications, and messages. we can't do that right
now.
3) From a development perspective, the links are not only more
readable for us and lead us to the code backing them more quickly, but
we can also paste such links into our ticketing system and find and
resolve issues more quickly rather than needed to create tickets that
describe the steps to get to a sub-page. We can also concatenate
suffixes from production links onto our private workspace or staging
links to test out fixes. Partners can send us links that are broken or
that they have a question about. Customers can point us at particular
pages that have a problem, or our help buttons can automaticaly send
us the page the user was on. We can use simple site performance and
uptime monitoring tools to see how our opensocial application is
performing if we have URLs. When we don't have real URLs in some
fashion, all of this stops and our development process slows down and
our customers and partners do not bother taking the time to send us
feedback, or they are frustrated by the process, and we can't easily
monitor the uptime or performance of our application from an end-user
perspective. We get reports like "on the NNN artist page on Orkut
there is a link to a concert on July 3rd at the Gorge amphitheatre..."
we can ping our web cluster for basic uptime/performance, but we can't
ping specific user or canvas pages to see whether something is broken.
This makes developing for and supporting OpenSocial painful.
4) Also from a development perspective, when we use real URLs a whole
class of URL-signing and parameter-passing bugs that have plagued each
container and which continue plaguing us daily here would have been
eliminated or minimally easier to track down. Encoding & signing " "
and "+" was broken. UTF8 characters like Mötley Crüe weren't working.
All this because containers don't know exactly what to encode or how
and are doing it within JSON blobs. It's unclear why this wheel of URL-
encoding is being reinvented.
5) if there are javascript errors anywhere on the page and javascript
stops running, navigation simply breaks, which is a horrendous user
experience. They can refresh, but they can't go anywhere within our
content -- not good and makes our applications and opensocial feel
flaky. This happens regularly.
6) Finally from a business model perspective, real URLs give us the
ability to create ads and external references that refer to our canvas
pages. It allows us to cross-promote our applications and our canvas
pages between different opensocial containers and facebook and our own
sites. It allows applications to cross-link with one another within a
containers, for promotional or other reasons. It allows us to email
users and give them a link to visit Hi5, Orkut, or MySpace versions of
iLike and add our application, and it allows us to do conversion-
tracking for installs from ads or email pointers and to optimize our
conversion to installation. We have none of this without URLs. The
most trivial example of this kind of utility which opensocial recently
lost traffic from is that we launched a new REM album for free
streaming on 3/24 exclusively with iLike. We were able to point users,
the press, record labels, and bands (including the band itself, REM)
to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem.
We have no URL to point press/analysts or the band to on Orkut, Hi5,
MySpace. On REM's "artist dashboard" on ilike we can point them to
their iLike-generated artist pages in non-OpenSocial containers so
they can preview how the songs and videos they are posting will appear
to their fans. We can't point them to their OpenSocial canvas pages.
You may think that this level of url cross-referencing is only useful
to complex/deep apps with many canvas pages like ours. This is not the
case -- even the smallest applications benefit from the business model
and development implications of URLs that can fall back on pure
navigation.
So, in a nutshell, here's the ideal API from my perspective: users can
copy-paste the URLs and we can construct urls offline or server-side
(given a known root, which ideally would be http://apps.<container>.com/ilike,
but fine with us if it's anything fixed like http://<container>/app_100)
and end up back in our application, but we actually use
requestNavigateTo under the covers which does all the good things
containers apparently need in all the different contexts and we can
support zany things like desktop/offline containers.
(the latter if the iframe host puts our docroot into place as they
host our manifest, or we could do that ourselves given a fixed base
URL)
Note that I would prefer this was shortened to take an URL instead of
making us do all the path, options crud to indicate a GET -- this is
just code that each application duplicates over and over again and we
should optimize the most common case. If you couldn't do that we could
stick with the longer convoluted arguments -- I don't really mind,
though I think it creates an irritating barrier to entry for
programmers to figure out for this API -- we would probably be
rewriting this content on the client by looking for rel="nofollow" or
some such on <a tags, like:
I think that, fundamentally, Nat is right. Links should be links. They've served the web quite well for decades. I'm personally quite annoyed with the way navigation works (or doesn't) in most widgets on the web, whether we're talking about opensocial gadgets or not. A lot of this is just tied to differences between normal web navigation and the javascript-heavy approaches being favored lately, and the architecture of opensocial is such that it strongly favors a javascript-heavy approach, to a certain extent at the expense of simpler applications that are more like traditional web pages.
This means that if I'm developing a widget that is more "application"-like, such as an email or IM client, the opensocial model works quite well, but if I'm developing something more "web page" like, such as a directory of artists, a simpler html-based approach is really more ideal.
Some other problems:
1. Not all containers have the same format. For a fixed container, it's trivial to dictate url format, because you only have to worry about one container and their url structure is all that matters. This works fine if you're only targeting just facebook or just myspce, but it stops working when you have to deal with 10 different containers, each with their own format.
We could mandate that all containers have some fixed url format, but I have a feeling that getting containers to agree on the format would be difficult at best. Rewriting is a pretty good idea, but it falls down when you have dynamically generated content, so we'd still have to come up with a function to generate dynamic links as well.
2. Gadgets are in iframes
This is probably a more fundamental issue. Navigation when you're in an iframe is difficult, because you've got two types of navigation: changing the parent page, and changing some iframe parameters. The former problem can mostly be solved by opening the link in a new tab. This doesn't quite cover situations such as linking to a different gadget or a different viewer, but it covers a lot of other situations. The latter problem is more complex.
3. Some containers don't want to allow navigation at all, or at least not in certain contexts.
On Thu, Mar 27, 2008 at 11:49 PM, Nat Brown (ilike.com) <nat...@gmail.com> wrote:
> There are a lot of painful implications to how requestNavigateTo works > within OpenSocial that should be addressed asap. Failure to fix these > issues will hinder developers and business models on the platform. > Here is my suggestion.
> Currently applications emit at the server or rewrite on the client > simple links into complicated javascript calls. For us in iLike, > instead of generating:
> Going through container javascript to navigate isn't the worst thing > in the world, but the fact that there is no real URL in the browser > has several perhaps non-obvious implications to the user experience, > business model, and technical layering which are worth thinking about > and fixing:
> 1) when links are real HREF's in the browser, users can see where > they are going when they hover over things, and they can copy/paste > links and send them to friends. They can DIGG them, they can post them > to facebook, they can copy them into google bookmarks. They can save > them in their browser favorites. They can open links in new tabs. They > can do none of these things in opensocial containers right now.
> 2) Links to canvas pages from activity stream items and any kind of > container notifications are also not going to work trivially -- gadget > javascript is not involved, we need to embed specific links into > activity streams, notifications, and messages. we can't do that right > now.
> 3) From a development perspective, the links are not only more > readable for us and lead us to the code backing them more quickly, but > we can also paste such links into our ticketing system and find and > resolve issues more quickly rather than needed to create tickets that > describe the steps to get to a sub-page. We can also concatenate > suffixes from production links onto our private workspace or staging > links to test out fixes. Partners can send us links that are broken or > that they have a question about. Customers can point us at particular > pages that have a problem, or our help buttons can automaticaly send > us the page the user was on. We can use simple site performance and > uptime monitoring tools to see how our opensocial application is > performing if we have URLs. When we don't have real URLs in some > fashion, all of this stops and our development process slows down and > our customers and partners do not bother taking the time to send us > feedback, or they are frustrated by the process, and we can't easily > monitor the uptime or performance of our application from an end-user > perspective. We get reports like "on the NNN artist page on Orkut > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > we can ping our web cluster for basic uptime/performance, but we can't > ping specific user or canvas pages to see whether something is broken. > This makes developing for and supporting OpenSocial painful.
> 4) Also from a development perspective, when we use real URLs a whole > class of URL-signing and parameter-passing bugs that have plagued each > container and which continue plaguing us daily here would have been > eliminated or minimally easier to track down. Encoding & signing " " > and "+" was broken. UTF8 characters like Mötley Crüe weren't working. > All this because containers don't know exactly what to encode or how > and are doing it within JSON blobs. It's unclear why this wheel of URL- > encoding is being reinvented.
> 5) if there are javascript errors anywhere on the page and javascript > stops running, navigation simply breaks, which is a horrendous user > experience. They can refresh, but they can't go anywhere within our > content -- not good and makes our applications and opensocial feel > flaky. This happens regularly.
> 6) Finally from a business model perspective, real URLs give us the > ability to create ads and external references that refer to our canvas > pages. It allows us to cross-promote our applications and our canvas > pages between different opensocial containers and facebook and our own > sites. It allows applications to cross-link with one another within a > containers, for promotional or other reasons. It allows us to email > users and give them a link to visit Hi5, Orkut, or MySpace versions of > iLike and add our application, and it allows us to do conversion- > tracking for installs from ads or email pointers and to optimize our > conversion to installation. We have none of this without URLs. The > most trivial example of this kind of utility which opensocial recently > lost traffic from is that we launched a new REM album for free > streaming on 3/24 exclusively with iLike. We were able to point users, > the press, record labels, and bands (including the band itself, REM) > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > We have no URL to point press/analysts or the band to on Orkut, Hi5, > MySpace. On REM's "artist dashboard" on ilike we can point them to > their iLike-generated artist pages in non-OpenSocial containers so > they can preview how the songs and videos they are posting will appear > to their fans. We can't point them to their OpenSocial canvas pages.
> You may think that this level of url cross-referencing is only useful > to complex/deep apps with many canvas pages like ours. This is not the > case -- even the smallest applications benefit from the business model > and development implications of URLs that can fall back on pure > navigation.
> So, in a nutshell, here's the ideal API from my perspective: users can > copy-paste the URLs and we can construct urls offline or server-side > (given a known root, which ideally would be http://apps. > <container>.com/ilike, > but fine with us if it's anything fixed like http://<container>/app_100) > and end up back in our application, but we actually use > requestNavigateTo under the covers which does all the good things > containers apparently need in all the different contexts and we can > support zany things like desktop/offline containers.
> (the latter if the iframe host puts our docroot into place as they > host our manifest, or we could do that ourselves given a fixed base > URL)
> Note that I would prefer this was shortened to take an URL instead of > making us do all the path, options crud to indicate a GET -- this is > just code that each application duplicates over and over again and we > should optimize the most common case. If you couldn't do that we could > stick with the longer convoluted arguments -- I don't really mind, > though I think it creates an irritating barrier to entry for > programmers to figure out for this API -- we would probably be > rewriting this content on the client by looking for rel="nofollow" or > some such on <a tags, like:
> There are a lot of painful implications to how requestNavigateTo works > within OpenSocial that should be addressed asap. Failure to fix these > issues will hinder developers and business models on the platform. > Here is my suggestion.
> Currently applications emit at the server or rewrite on the client > simple links into complicated javascript calls. For us in iLike, > instead of generating:
> Going through container javascript to navigate isn't the worst thing > in the world, but the fact that there is no real URL in the browser > has several perhaps non-obvious implications to the user experience, > business model, and technical layering which are worth thinking about > and fixing:
> 1) when links are real HREF's in the browser, users can see where > they are going when they hover over things, and they can copy/paste > links and send them to friends. They can DIGG them, they can post them > to facebook, they can copy them into google bookmarks. They can save > them in their browser favorites. They can open links in new tabs. They > can do none of these things in opensocial containers right now.
> 2) Links to canvas pages from activity stream items and any kind of > container notifications are also not going to work trivially -- gadget > javascript is not involved, we need to embed specific links into > activity streams, notifications, and messages. we can't do that right > now.
> 3) From a development perspective, the links are not only more > readable for us and lead us to the code backing them more quickly, but > we can also paste such links into our ticketing system and find and > resolve issues more quickly rather than needed to create tickets that > describe the steps to get to a sub-page. We can also concatenate > suffixes from production links onto our private workspace or staging > links to test out fixes. Partners can send us links that are broken or > that they have a question about. Customers can point us at particular > pages that have a problem, or our help buttons can automaticaly send > us the page the user was on. We can use simple site performance and > uptime monitoring tools to see how our opensocial application is > performing if we have URLs. When we don't have real URLs in some > fashion, all of this stops and our development process slows down and > our customers and partners do not bother taking the time to send us > feedback, or they are frustrated by the process, and we can't easily > monitor the uptime or performance of our application from an end-user > perspective. We get reports like "on the NNN artist page on Orkut > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > we can ping our web cluster for basic uptime/performance, but we can't > ping specific user or canvas pages to see whether something is broken. > This makes developing for and supporting OpenSocial painful.
> 4) Also from a development perspective, when we use real URLs a whole > class of URL-signing and parameter-passing bugs that have plagued each > container and which continue plaguing us daily here would have been > eliminated or minimally easier to track down. Encoding & signing " " > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > g. > All this because containers don't know exactly what to encode or how > and are doing it within JSON blobs. It's unclear why this wheel of > URL- > encoding is being reinvented.
> 5) if there are javascript errors anywhere on the page and javascript > stops running, navigation simply breaks, which is a horrendous user > experience. They can refresh, but they can't go anywhere within our > content -- not good and makes our applications and opensocial feel > flaky. This happens regularly.
> 6) Finally from a business model perspective, real URLs give us the > ability to create ads and external references that refer to our canvas > pages. It allows us to cross-promote our applications and our canvas > pages between different opensocial containers and facebook and our own > sites. It allows applications to cross-link with one another within a > containers, for promotional or other reasons. It allows us to email > users and give them a link to visit Hi5, Orkut, or MySpace versions of > iLike and add our application, and it allows us to do conversion- > tracking for installs from ads or email pointers and to optimize our > conversion to installation. We have none of this without URLs. The > most trivial example of this kind of utility which opensocial recently > lost traffic from is that we launched a new REM album for free > streaming on 3/24 exclusively with iLike. We were able to point users, > the press, record labels, and bands (including the band itself, REM) > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > We have no URL to point press/analysts or the band to on Orkut, Hi5, > MySpace. On REM's "artist dashboard" on ilike we can point them to > their iLike-generated artist pages in non-OpenSocial containers so > they can preview how the songs and videos they are posting will appear > to their fans. We can't point them to their OpenSocial canvas pages.
> You may think that this level of url cross-referencing is only useful > to complex/deep apps with many canvas pages like ours. This is not the > case -- even the smallest applications benefit from the business model > and development implications of URLs that can fall back on pure > navigation.
> So, in a nutshell, here's the ideal API from my perspective: users can > copy-paste the URLs and we can construct urls offline or server-side > (given a known root, which ideally would be http:// > apps.<container>.com/ilike, > but fine with us if it's anything fixed like http://<container>/ > app_100) > and end up back in our application, but we actually use > requestNavigateTo under the covers which does all the good things > containers apparently need in all the different contexts and we can > support zany things like desktop/offline containers.
> (the latter if the iframe host puts our docroot into place as they > host our manifest, or we could do that ourselves given a fixed base > URL)
> Note that I would prefer this was shortened to take an URL instead of > making us do all the path, options crud to indicate a GET -- this is > just code that each application duplicates over and over again and we > should optimize the most common case. If you couldn't do that we could > stick with the longer convoluted arguments -- I don't really mind, > though I think it creates an irritating barrier to entry for > programmers to figure out for this API -- we would probably be > rewriting this content on the client by looking for rel="nofollow" or > some such on <a tags, like:
I think it will be difficult to standardize URLs across containers, even given a common server base. One particular problem will be with more AJAX-y applications - even if we all agree, some will want to navigate to http://container.com/*#ilike?params* and some to */ilike?params* (the # allows you to fake navigation without an actual browser navigation request). It's worth starting the discussion to see if we could all agree on a convention, but I'm not sure we'll converge.
Would it work if we had an API for getting a URL for a given container, i.e.: opensocial.getUrlFor(app, path, params). This would allow containers to have their own URL schemes but also support getting a URL you could actually put into links. It's a bit less convenient, as you wouldn't be able to easily generate per-container URLs from your own servers, but it avoids trying to get consensus on URL structures which seems a little daunting.
On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> wrote:
> +1 - blogspot, for example, really really wants real linkable urls > wherever possible.
> -John
> On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > <nat...@gmail.com> wrote:
> > There are a lot of painful implications to how requestNavigateTo works > > within OpenSocial that should be addressed asap. Failure to fix these > > issues will hinder developers and business models on the platform. > > Here is my suggestion.
> > Currently applications emit at the server or rewrite on the client > > simple links into complicated javascript calls. For us in iLike, > > instead of generating:
> > Going through container javascript to navigate isn't the worst thing > > in the world, but the fact that there is no real URL in the browser > > has several perhaps non-obvious implications to the user experience, > > business model, and technical layering which are worth thinking about > > and fixing:
> > 1) when links are real HREF's in the browser, users can see where > > they are going when they hover over things, and they can copy/paste > > links and send them to friends. They can DIGG them, they can post them > > to facebook, they can copy them into google bookmarks. They can save > > them in their browser favorites. They can open links in new tabs. They > > can do none of these things in opensocial containers right now.
> > 2) Links to canvas pages from activity stream items and any kind of > > container notifications are also not going to work trivially -- gadget > > javascript is not involved, we need to embed specific links into > > activity streams, notifications, and messages. we can't do that right > > now.
> > 3) From a development perspective, the links are not only more > > readable for us and lead us to the code backing them more quickly, but > > we can also paste such links into our ticketing system and find and > > resolve issues more quickly rather than needed to create tickets that > > describe the steps to get to a sub-page. We can also concatenate > > suffixes from production links onto our private workspace or staging > > links to test out fixes. Partners can send us links that are broken or > > that they have a question about. Customers can point us at particular > > pages that have a problem, or our help buttons can automaticaly send > > us the page the user was on. We can use simple site performance and > > uptime monitoring tools to see how our opensocial application is > > performing if we have URLs. When we don't have real URLs in some > > fashion, all of this stops and our development process slows down and > > our customers and partners do not bother taking the time to send us > > feedback, or they are frustrated by the process, and we can't easily > > monitor the uptime or performance of our application from an end-user > > perspective. We get reports like "on the NNN artist page on Orkut > > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > > we can ping our web cluster for basic uptime/performance, but we can't > > ping specific user or canvas pages to see whether something is broken. > > This makes developing for and supporting OpenSocial painful.
> > 4) Also from a development perspective, when we use real URLs a whole > > class of URL-signing and parameter-passing bugs that have plagued each > > container and which continue plaguing us daily here would have been > > eliminated or minimally easier to track down. Encoding & signing " " > > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > > g. > > All this because containers don't know exactly what to encode or how > > and are doing it within JSON blobs. It's unclear why this wheel of > > URL- > > encoding is being reinvented.
> > 5) if there are javascript errors anywhere on the page and javascript > > stops running, navigation simply breaks, which is a horrendous user > > experience. They can refresh, but they can't go anywhere within our > > content -- not good and makes our applications and opensocial feel > > flaky. This happens regularly.
> > 6) Finally from a business model perspective, real URLs give us the > > ability to create ads and external references that refer to our canvas > > pages. It allows us to cross-promote our applications and our canvas > > pages between different opensocial containers and facebook and our own > > sites. It allows applications to cross-link with one another within a > > containers, for promotional or other reasons. It allows us to email > > users and give them a link to visit Hi5, Orkut, or MySpace versions of > > iLike and add our application, and it allows us to do conversion- > > tracking for installs from ads or email pointers and to optimize our > > conversion to installation. We have none of this without URLs. The > > most trivial example of this kind of utility which opensocial recently > > lost traffic from is that we launched a new REM album for free > > streaming on 3/24 exclusively with iLike. We were able to point users, > > the press, record labels, and bands (including the band itself, REM) > > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > their iLike-generated artist pages in non-OpenSocial containers so > > they can preview how the songs and videos they are posting will appear > > to their fans. We can't point them to their OpenSocial canvas pages.
> > You may think that this level of url cross-referencing is only useful > > to complex/deep apps with many canvas pages like ours. This is not the > > case -- even the smallest applications benefit from the business model > > and development implications of URLs that can fall back on pure > > navigation.
> > So, in a nutshell, here's the ideal API from my perspective: users can > > copy-paste the URLs and we can construct urls offline or server-side > > (given a known root, which ideally would be http:// > > apps.<container>.com/ilike, > > but fine with us if it's anything fixed like http://<container>/ > > app_100) > > and end up back in our application, but we actually use > > requestNavigateTo under the covers which does all the good things > > containers apparently need in all the different contexts and we can > > support zany things like desktop/offline containers.
> > (the latter if the iframe host puts our docroot into place as they > > host our manifest, or we could do that ourselves given a fixed base > > URL)
> > Note that I would prefer this was shortened to take an URL instead of > > making us do all the path, options crud to indicate a GET -- this is > > just code that each application duplicates over and over again and we > > should optimize the most common case. If you couldn't do that we could > > stick with the longer convoluted arguments -- I don't really mind, > > though I think it creates an irritating barrier to entry for > > programmers to figure out for this API -- we would probably be > > rewriting this content on the client by looking for rel="nofollow" or > > some such on <a tags, like:
> I think it will be difficult to standardize URLs across containers, > even given a common server base. One particular problem will be with > more AJAX-y applications - even if we all agree, some will want to > navigate to http://container.com/#ilike?params and some to /ilike? > params (the # allows you to fake navigation without an actual > browser navigation request). It's worth starting the discussion to > see if we could all agree on a convention, but I'm not sure we'll > converge.
> Would it work if we had an API for getting a URL for a given > container, i.e.: opensocial.getUrlFor(app, path, params). This would > allow containers to have their own URL schemes but also support > getting a URL you could actually put into links. It's a bit less > convenient, as you wouldn't be able to easily generate per-container > URLs from your own servers,
> but it avoids trying to get consensus on URL structures which seems > a little daunting.
> Evan
> On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> > wrote:
> +1 - blogspot, for example, really really wants real linkable urls > wherever possible.
> -John
> On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > <nat...@gmail.com> wrote:
> > There are a lot of painful implications to how requestNavigateTo > works > > within OpenSocial that should be addressed asap. Failure to fix > these > > issues will hinder developers and business models on the platform. > > Here is my suggestion.
> > Currently applications emit at the server or rewrite on the client > > simple links into complicated javascript calls. For us in iLike, > > instead of generating:
> > Going through container javascript to navigate isn't the worst thing > > in the world, but the fact that there is no real URL in the browser > > has several perhaps non-obvious implications to the user experience, > > business model, and technical layering which are worth thinking > about > > and fixing:
> > 1) when links are real HREF's in the browser, users can see where > > they are going when they hover over things, and they can copy/paste > > links and send them to friends. They can DIGG them, they can post > them > > to facebook, they can copy them into google bookmarks. They can save > > them in their browser favorites. They can open links in new tabs. > They > > can do none of these things in opensocial containers right now.
> > 2) Links to canvas pages from activity stream items and any kind of > > container notifications are also not going to work trivially -- > gadget > > javascript is not involved, we need to embed specific links into > > activity streams, notifications, and messages. we can't do that > right > > now.
> > 3) From a development perspective, the links are not only more > > readable for us and lead us to the code backing them more quickly, > but > > we can also paste such links into our ticketing system and find and > > resolve issues more quickly rather than needed to create tickets > that > > describe the steps to get to a sub-page. We can also concatenate > > suffixes from production links onto our private workspace or staging > > links to test out fixes. Partners can send us links that are > broken or > > that they have a question about. Customers can point us at > particular > > pages that have a problem, or our help buttons can automaticaly send > > us the page the user was on. We can use simple site performance and > > uptime monitoring tools to see how our opensocial application is > > performing if we have URLs. When we don't have real URLs in some > > fashion, all of this stops and our development process slows down > and > > our customers and partners do not bother taking the time to send us > > feedback, or they are frustrated by the process, and we can't easily > > monitor the uptime or performance of our application from an end- > user > > perspective. We get reports like "on the NNN artist page on Orkut > > there is a link to a concert on July 3rd at the Gorge > amphitheatre..." > > we can ping our web cluster for basic uptime/performance, but we > can't > > ping specific user or canvas pages to see whether something is > broken. > > This makes developing for and supporting OpenSocial painful.
> > 4) Also from a development perspective, when we use real URLs a > whole > > class of URL-signing and parameter-passing bugs that have plagued > each > > container and which continue plaguing us daily here would have been > > eliminated or minimally easier to track down. Encoding & signing " " > > and "+" was broken. UTF8 characters like Mötley Crüe weren't work > in > > g. > > All this because containers don't know exactly what to encode or how > > and are doing it within JSON blobs. It's unclear why this wheel of > > URL- > > encoding is being reinvented.
> > 5) if there are javascript errors anywhere on the page and > javascript > > stops running, navigation simply breaks, which is a horrendous user > > experience. They can refresh, but they can't go anywhere within our > > content -- not good and makes our applications and opensocial feel > > flaky. This happens regularly.
> > 6) Finally from a business model perspective, real URLs give us the > > ability to create ads and external references that refer to our > canvas > > pages. It allows us to cross-promote our applications and our canvas > > pages between different opensocial containers and facebook and our > own > > sites. It allows applications to cross-link with one another > within a > > containers, for promotional or other reasons. It allows us to email > > users and give them a link to visit Hi5, Orkut, or MySpace > versions of > > iLike and add our application, and it allows us to do conversion- > > tracking for installs from ads or email pointers and to optimize our > > conversion to installation. We have none of this without URLs. The > > most trivial example of this kind of utility which opensocial > recently > > lost traffic from is that we launched a new REM album for free > > streaming on 3/24 exclusively with iLike. We were able to point > users, > > the press, record labels, and bands (including the band itself, REM) > > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem > . > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > their iLike-generated artist pages in non-OpenSocial containers so > > they can preview how the songs and videos they are posting will > appear > > to their fans. We can't point them to their OpenSocial canvas pages.
> > You may think that this level of url cross-referencing is only > useful > > to complex/deep apps with many canvas pages like ours. This is not > the > > case -- even the smallest applications benefit from the business > model > > and development implications of URLs that can fall back on pure > > navigation.
> > So, in a nutshell, here's the ideal API from my perspective: users > can > > copy-paste the URLs and we can construct urls offline or server-side > > (given a known root, which ideally would be http:// > > apps.<container>.com/ilike, > > but fine with us if it's anything fixed like http://<container>/ > > app_100) > > and end up back in our application, but we actually use > > requestNavigateTo under the covers which does all the good things > > containers apparently need in all the different contexts and we can > > support zany things like desktop/offline containers.
> > (the latter if the iframe host puts our docroot into place as they > > host our manifest, or we could do that ourselves given a fixed base > > URL)
> > Note that I would prefer this was shortened to take an URL instead > of > > making us do all the path, options crud to indicate a GET -- this is > > just code that each application duplicates over and over again and > we > > should optimize the most common case. If you couldn't do that we > could > > stick with the longer convoluted arguments -- I don't really mind, > > though I think it creates an irritating barrier to entry for > > programmers to figure out for this API -- we would probably be > > rewriting this content on the client by looking for rel="nofollow" > or > > some such on <a tags, like:
> > Which we would convert/rewrite at the client to have the onClick= > > within them.
> > Thx, n@
> --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "OpenSocial and Gadgets Specification Discussion" group. > To post to this group, send email to opensocial-and-gadgets-spec@googlegroups.com > To unsubscribe from this group, send
We could have a JS method and/or a RESTful method for returning the template, but the template would be assumed to be effectively permanent so apps wouldn't actually have to query it at runtime. That way they could build URLs on the server side.
On Fri, Mar 28, 2008 at 8:14 AM, Evan Gilbert <uid...@google.com> wrote: > Nat - all really good points.
> I think it will be difficult to standardize URLs across containers, even > given a common server base. One particular problem will be with more AJAX-y > applications - even if we all agree, some will want to navigate to > http://container.com/*#ilike?params* and some to */ilike?params* (the # > allows you to fake navigation without an actual browser navigation request). > It's worth starting the discussion to see if we could all agree on a > convention, but I'm not sure we'll converge.
> Would it work if we had an API for getting a URL for a given container, > i.e.: opensocial.getUrlFor(app, path, params). This would allow containers > to have their own URL schemes but also support getting a URL you could > actually put into links. It's a bit less convenient, as you wouldn't be able > to easily generate per-container URLs from your own servers, but it avoids > trying to get consensus on URL structures which seems a little daunting.
> Evan
> On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> wrote:
> > +1 - blogspot, for example, really really wants real linkable urls > > wherever possible.
> > -John
> > On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > > <nat...@gmail.com> wrote:
> > > There are a lot of painful implications to how requestNavigateTo works > > > within OpenSocial that should be addressed asap. Failure to fix these > > > issues will hinder developers and business models on the platform. > > > Here is my suggestion.
> > > Currently applications emit at the server or rewrite on the client > > > simple links into complicated javascript calls. For us in iLike, > > > instead of generating:
> > > Going through container javascript to navigate isn't the worst thing > > > in the world, but the fact that there is no real URL in the browser > > > has several perhaps non-obvious implications to the user experience, > > > business model, and technical layering which are worth thinking about > > > and fixing:
> > > 1) when links are real HREF's in the browser, users can see where > > > they are going when they hover over things, and they can copy/paste > > > links and send them to friends. They can DIGG them, they can post them > > > to facebook, they can copy them into google bookmarks. They can save > > > them in their browser favorites. They can open links in new tabs. They > > > can do none of these things in opensocial containers right now.
> > > 2) Links to canvas pages from activity stream items and any kind of > > > container notifications are also not going to work trivially -- gadget > > > javascript is not involved, we need to embed specific links into > > > activity streams, notifications, and messages. we can't do that right > > > now.
> > > 3) From a development perspective, the links are not only more > > > readable for us and lead us to the code backing them more quickly, but > > > we can also paste such links into our ticketing system and find and > > > resolve issues more quickly rather than needed to create tickets that > > > describe the steps to get to a sub-page. We can also concatenate > > > suffixes from production links onto our private workspace or staging > > > links to test out fixes. Partners can send us links that are broken or > > > that they have a question about. Customers can point us at particular > > > pages that have a problem, or our help buttons can automaticaly send > > > us the page the user was on. We can use simple site performance and > > > uptime monitoring tools to see how our opensocial application is > > > performing if we have URLs. When we don't have real URLs in some > > > fashion, all of this stops and our development process slows down and > > > our customers and partners do not bother taking the time to send us > > > feedback, or they are frustrated by the process, and we can't easily > > > monitor the uptime or performance of our application from an end-user > > > perspective. We get reports like "on the NNN artist page on Orkut > > > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > > > we can ping our web cluster for basic uptime/performance, but we can't > > > ping specific user or canvas pages to see whether something is broken. > > > This makes developing for and supporting OpenSocial painful.
> > > 4) Also from a development perspective, when we use real URLs a whole > > > class of URL-signing and parameter-passing bugs that have plagued each > > > container and which continue plaguing us daily here would have been > > > eliminated or minimally easier to track down. Encoding & signing " " > > > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > > > g. > > > All this because containers don't know exactly what to encode or how > > > and are doing it within JSON blobs. It's unclear why this wheel of > > > URL- > > > encoding is being reinvented.
> > > 5) if there are javascript errors anywhere on the page and javascript > > > stops running, navigation simply breaks, which is a horrendous user > > > experience. They can refresh, but they can't go anywhere within our > > > content -- not good and makes our applications and opensocial feel > > > flaky. This happens regularly.
> > > 6) Finally from a business model perspective, real URLs give us the > > > ability to create ads and external references that refer to our canvas > > > pages. It allows us to cross-promote our applications and our canvas > > > pages between different opensocial containers and facebook and our own > > > sites. It allows applications to cross-link with one another within a > > > containers, for promotional or other reasons. It allows us to email > > > users and give them a link to visit Hi5, Orkut, or MySpace versions of > > > iLike and add our application, and it allows us to do conversion- > > > tracking for installs from ads or email pointers and to optimize our > > > conversion to installation. We have none of this without URLs. The > > > most trivial example of this kind of utility which opensocial recently > > > lost traffic from is that we launched a new REM album for free > > > streaming on 3/24 exclusively with iLike. We were able to point users, > > > the press, record labels, and bands (including the band itself, REM) > > > to http://apps.facebook.com/ilike/rem and to http://www.ilike.com/rem. > > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > > their iLike-generated artist pages in non-OpenSocial containers so > > > they can preview how the songs and videos they are posting will appear > > > to their fans. We can't point them to their OpenSocial canvas pages.
> > > You may think that this level of url cross-referencing is only useful > > > to complex/deep apps with many canvas pages like ours. This is not the > > > case -- even the smallest applications benefit from the business model > > > and development implications of URLs that can fall back on pure > > > navigation.
> > > So, in a nutshell, here's the ideal API from my perspective: users can > > > copy-paste the URLs and we can construct urls offline or server-side > > > (given a known root, which ideally would be http:// > > > apps.<container>.com/ilike, > > > but fine with us if it's anything fixed like http://<container>/ > > > app_100) > > > and end up back in our application, but we actually use > > > requestNavigateTo under the covers which does all the good things > > > containers apparently need in all the different contexts and we can > > > support zany things like desktop/offline containers.
> > > (the latter if the iframe host puts our docroot into place as they > > > host our manifest, or we could do that ourselves given a fixed base > > > URL)
> > > Note that I would prefer this was shortened to take an URL instead of > > > making us do all the path, options crud to indicate a GET -- this is > > > just code that each application duplicates over and over again and we > > > should optimize the most common case. If you couldn't do that we could > > > stick with the longer convoluted arguments -- I don't really mind, > > > though I think it creates an irritating barrier to entry for > > > programmers to figure out for this API -- we would probably be > > > rewriting this content on the client by looking for rel="nofollow" or > > > some such on <a tags, like:
> We could have a JS method and/or a RESTful method for returning the > template, but the template would be assumed to be effectively permanent so > apps wouldn't actually have to query it at runtime. That way they could > build URLs on the server side.
You can't really make it permanent, because that would prevent the container from ever changing their url structure, which may become necessary for other reasons (such as domain name changes). It's also quite possible that you'd have something like locale information in the url, e.g.:
I don't think just adding the container domain to the template resolves this, because then you'd just need another API for getting the container domain.
There's also an issue with parameter naming. If the site has some parameters passed in the query string, and other parameters are passed to the gadget, you've got a conflict. Sites that have taken care to construct urls to get around this wouldn't be affected, but otherwise a parameter naming scheme would be necessary, or a function (REST / js) would be necessary to produce the final url.
> On Fri, Mar 28, 2008 at 8:14 AM, Evan Gilbert <uid...@google.com> wrote:
> > Nat - all really good points.
> > I think it will be difficult to standardize URLs across containers, even > > given a common server base. One particular problem will be with more AJAX-y > > applications - even if we all agree, some will want to navigate to > > http://container.com/*#ilike?params* and some to */ilike?params* (the # > > allows you to fake navigation without an actual browser navigation request). > > It's worth starting the discussion to see if we could all agree on a > > convention, but I'm not sure we'll converge.
> > Would it work if we had an API for getting a URL for a given container, > > i.e.: opensocial.getUrlFor(app, path, params). This would allow > > containers to have their own URL schemes but also support getting a URL you > > could actually put into links. It's a bit less convenient, as you wouldn't > > be able to easily generate per-container URLs from your own servers, but it > > avoids trying to get consensus on URL structures which seems a little > > daunting.
> > Evan
> > On Fri, Mar 28, 2008 at 3:51 AM, John Panzer <jpan...@google.com> wrote:
> > > +1 - blogspot, for example, really really wants real linkable urls > > > wherever possible.
> > > -John
> > > On Mar 27, 2008, at 11:49 PM, "Nat Brown (ilike.com)" > > > <nat...@gmail.com> wrote:
> > > > There are a lot of painful implications to how requestNavigateTo > > > works > > > > within OpenSocial that should be addressed asap. Failure to fix > > > these > > > > issues will hinder developers and business models on the platform. > > > > Here is my suggestion.
> > > > Currently applications emit at the server or rewrite on the client > > > > simple links into complicated javascript calls. For us in iLike, > > > > instead of generating:
> > > > Going through container javascript to navigate isn't the worst thing > > > > in the world, but the fact that there is no real URL in the browser > > > > has several perhaps non-obvious implications to the user experience, > > > > business model, and technical layering which are worth thinking > > > about > > > > and fixing:
> > > > 1) when links are real HREF's in the browser, users can see where > > > > they are going when they hover over things, and they can copy/paste > > > > links and send them to friends. They can DIGG them, they can post > > > them > > > > to facebook, they can copy them into google bookmarks. They can save > > > > them in their browser favorites. They can open links in new tabs. > > > They > > > > can do none of these things in opensocial containers right now.
> > > > 2) Links to canvas pages from activity stream items and any kind of > > > > container notifications are also not going to work trivially -- > > > gadget > > > > javascript is not involved, we need to embed specific links into > > > > activity streams, notifications, and messages. we can't do that > > > right > > > > now.
> > > > 3) From a development perspective, the links are not only more > > > > readable for us and lead us to the code backing them more quickly, > > > but > > > > we can also paste such links into our ticketing system and find and > > > > resolve issues more quickly rather than needed to create tickets > > > that > > > > describe the steps to get to a sub-page. We can also concatenate > > > > suffixes from production links onto our private workspace or staging > > > > links to test out fixes. Partners can send us links that are broken > > > or > > > > that they have a question about. Customers can point us at > > > particular > > > > pages that have a problem, or our help buttons can automaticaly send > > > > us the page the user was on. We can use simple site performance and > > > > uptime monitoring tools to see how our opensocial application is > > > > performing if we have URLs. When we don't have real URLs in some > > > > fashion, all of this stops and our development process slows down > > > and > > > > our customers and partners do not bother taking the time to send us > > > > feedback, or they are frustrated by the process, and we can't easily > > > > monitor the uptime or performance of our application from an > > > end-user > > > > perspective. We get reports like "on the NNN artist page on Orkut > > > > there is a link to a concert on July 3rd at the Gorge > > > amphitheatre..." > > > > we can ping our web cluster for basic uptime/performance, but we > > > can't > > > > ping specific user or canvas pages to see whether something is > > > broken. > > > > This makes developing for and supporting OpenSocial painful.
> > > > 4) Also from a development perspective, when we use real URLs a > > > whole > > > > class of URL-signing and parameter-passing bugs that have plagued > > > each > > > > container and which continue plaguing us daily here would have been > > > > eliminated or minimally easier to track down. Encoding & signing " " > > > > and "+" was broken. UTF8 characters like Mötley Crüe weren't workin > > > > g. > > > > All this because containers don't know exactly what to encode or how > > > > and are doing it within JSON blobs. It's unclear why this wheel of > > > > URL- > > > > encoding is being reinvented.
> > > > 5) if there are javascript errors anywhere on the page and > > > javascript > > > > stops running, navigation simply breaks, which is a horrendous user > > > > experience. They can refresh, but they can't go anywhere within our > > > > content -- not good and makes our applications and opensocial feel > > > > flaky. This happens regularly.
> > > > 6) Finally from a business model perspective, real URLs give us the > > > > ability to create ads and external references that refer to our > > > canvas > > > > pages. It allows us to cross-promote our applications and our canvas > > > > pages between different opensocial containers and facebook and our > > > own > > > > sites. It allows applications to cross-link with one another within > > > a > > > > containers, for promotional or other reasons. It allows us to email > > > > users and give them a link to visit Hi5, Orkut, or MySpace versions > > > of > > > > iLike and add our application, and it allows us to do conversion- > > > > tracking for installs from ads or email pointers and to optimize our > > > > conversion to installation. We have none of this without URLs. The > > > > most trivial example of this kind of utility which opensocial > > > recently > > > > lost traffic from is that we launched a new REM album for free > > > > streaming on 3/24 exclusively with iLike. We were able to point > > > users, > > > > the press, record labels, and bands (including the band itself, REM) > > > > to http://apps.facebook.com/ilike/rem and to > > > http://www.ilike.com/rem. > > > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > > > their iLike-generated artist pages in non-OpenSocial containers so > > > > they can preview how the songs and videos they are posting will > > > appear > > > > to their fans. We can't point them to their OpenSocial canvas pages.
> > > > You may think that this level of url cross-referencing is only > > > useful > > > > to complex/deep apps with many canvas pages like ours. This is not > > > the > > > > case -- even the smallest applications benefit from the business > > > model > > > > and development implications of URLs that can fall back on pure > > > > navigation.
> > > > So, in a nutshell, here's the ideal API from my perspective: users > > > can > > > > copy-paste the URLs and we can construct urls offline or server-side > > > > (given a known root, which ideally would be http:// > > > > apps.<container>.com/ilike, > > > > but
> > We could have a JS method and/or a RESTful method for returning the > > template, but the template would be assumed to be effectively permanent so > > apps wouldn't actually have to query it at runtime. That way they could > > build URLs on the server side.
> You can't really make it permanent, because that would prevent the > container from ever changing their url structure, which may become necessary > for other reasons (such as domain name changes).
Although I agree in principle, I think in practice most sites try pretty hard to preserve their old URLs.
At worst, the method could return a TTL indicating how long an app can rely on the template.
> It's also quite possible that you'd have something like locale information > in the url, e.g.:
> I don't think just adding the container domain to the template resolves > this, because then you'd just need another API for getting the container > domain.
I'd be in favor of leaving this out of the spec until a container actually requests it.
> There's also an issue with parameter naming. If the site has some > parameters passed in the query string, and other parameters are passed to > the gadget, you've got a conflict. Sites that have taken care to construct > urls to get around this wouldn't be affected, but otherwise a parameter > naming scheme would be necessary, or a function (REST / js) would be > necessary to produce the final url.
Parameter naming could probably be expressed through some simple pattern rules, right?
I agree that we lose some theoretical generality by trying to create a static policy instead of requiring all URLs to be calculated at runtime, all the time. However, there are huge developer benefits to being able to create URLs on the server without pinging an OpenSocial API; I think in practice most containers will want relatively long-lived URLs; and I think most naming rules will be easily expressible. So I recommend that we design this for reasonable extensibility but we don't let somewhat speculative cases prevent us from enabling easy URL rules that will work on all current containers.
> There are a lot of painful implications to howrequestNavigateToworks
> within OpenSocial that should be addressed asap. Failure to fix these
> issues will hinder developers and business models on the platform.
> Here is my suggestion.
> Currently applications emit at the server or rewrite on the client
> simple links into complicated javascript calls. For us in iLike,
> instead of generating:
> Going through container javascript to navigate isn't the worst thing
> in the world, but the fact that there is no real URL in the browser
> has several perhaps non-obvious implications to the user experience,
> business model, and technical layering which are worth thinking about
> and fixing:
> 1) when links are real HREF's in the browser, users can see where
> they are going when they hover over things, and they can copy/paste
> links and send them to friends. They can DIGG them, they can post them
> to facebook, they can copy them into google bookmarks. They can save
> them in their browser favorites. They can open links in new tabs. They
> can do none of these things in opensocial containers right now.
> 2) Links to canvas pages from activity stream items and any kind of
> container notifications are also not going to work trivially -- gadget
> javascript is not involved, we need to embed specific links into
> activity streams, notifications, and messages. we can't do that right
> now.
> 3) From a development perspective, the links are not only more
> readable for us and lead us to the code backing them more quickly, but
> we can also paste such links into our ticketing system and find and
> resolve issues more quickly rather than needed to create tickets that
> describe the steps to get to a sub-page. We can also concatenate
> suffixes from production links onto our private workspace or staging
> links to test out fixes. Partners can send us links that are broken or
> that they have a question about. Customers can point us at particular
> pages that have a problem, or our help buttons can automaticaly send
> us the page the user was on. We can use simple site performance and
> uptime monitoring tools to see how our opensocial application is
> performing if we have URLs. When we don't have real URLs in some
> fashion, all of this stops and our development process slows down and
> our customers and partners do not bother taking the time to send us
> feedback, or they are frustrated by the process, and we can't easily
> monitor the uptime or performance of our application from an end-user
> perspective. We get reports like "on the NNN artist page on Orkut
> there is a link to a concert on July 3rd at the Gorge amphitheatre..."
> we can ping our web cluster for basic uptime/performance, but we can't
> ping specific user or canvas pages to see whether something is broken.
> This makes developing for and supporting OpenSocial painful.
> 4) Also from a development perspective, when we use real URLs a whole
> class of URL-signing and parameter-passing bugs that have plagued each
> container and which continue plaguing us daily here would have been
> eliminated or minimally easier to track down. Encoding & signing " "
> and "+" was broken. UTF8 characters like Mötley Crüe weren't working.
> All this because containers don't know exactly what to encode or how
> and are doing it within JSON blobs. It's unclear why this wheel of URL-
> encoding is being reinvented.
> 5) if there are javascript errors anywhere on the page and javascript
> stops running, navigation simply breaks, which is a horrendous user
> experience. They can refresh, but they can't go anywhere within our
> content -- not good and makes our applications and opensocial feel
> flaky. This happens regularly.
> 6) Finally from a business model perspective, real URLs give us the
> ability to create ads and external references that refer to our canvas
> pages. It allows us to cross-promote our applications and our canvas
> pages between different opensocial containers and facebook and our own
> sites. It allows applications to cross-link with one another within a
> containers, for promotional or other reasons. It allows us to email
> users and give them a link to visit Hi5, Orkut, or MySpace versions of
> iLike and add our application, and it allows us to do conversion-
> tracking for installs from ads or email pointers and to optimize our
> conversion to installation. We have none of this without URLs. The
> most trivial example of this kind of utility which opensocial recently
> lost traffic from is that we launched a new REM album for free
> streaming on 3/24 exclusively with iLike. We were able to point users,
> the press, record labels, and bands (including the band itself, REM)
> tohttp://apps.facebook.com/ilike/remand tohttp://www.ilike.com/rem.
> We have no URL to point press/analysts or the band to on Orkut, Hi5,
> MySpace. On REM's "artist dashboard" on ilike we can point them to
> their iLike-generated artist pages in non-OpenSocial containers so
> they can preview how the songs and videos they are posting will appear
> to their fans. We can't point them to their OpenSocial canvas pages.
> You may think that this level of url cross-referencing is only useful
> to complex/deep apps with many canvas pages like ours. This is not the
> case -- even the smallest applications benefit from the business model
> and development implications of URLs that can fall back on pure
> navigation.
> So, in a nutshell, here's the ideal API from my perspective: users can
> copy-paste the URLs and we can construct urls offline or server-side
> (given a known root, which ideally would behttp://apps.<container>.com/ilike,
> but fine with us if it's anything fixed like http://<container>/app_100)
> and end up back in our application, but we actually userequestNavigateTounder the covers which does all the good things
> containers apparently need in all the different contexts and we can
> support zany things like desktop/offline containers.
> (the latter if the iframe host puts our docroot into place as they
> host our manifest, or we could do that ourselves given a fixed base
> URL)
> Note that I would prefer this was shortened to take an URL instead of
> making us do all the path, options crud to indicate a GET -- this is
> just code that each application duplicates over and over again and we
> should optimize the most common case. If you couldn't do that we could
> stick with the longer convoluted arguments -- I don't really mind,
> though I think it creates an irritating barrier to entry for
> programmers to figure out for this API -- we would probably be
> rewriting this content on the client by looking for rel="nofollow" or
> some such on <a tags, like:
In keeping with the proposal for spec changes that Cassie just announced (+1 on that BTW), let's make an official call for spec change on this topic.
I'll officially propose what I informally proposed above: we should add JS and RESTful API methods that allow apps to fetch a (long-lived) URL template.
This returns a string containing "${}" variables. The three supported variables are: - name: the name or id of the application - path: an application-defined path string - params: application-defined parameters, query-encoded.
For discussion: - Should we add other parameters, e.g. locale? - Should we add configuration for parameter prefixing as proposed by Kevin? (In that case containerUrlTemplate might return an object instead of just a string, and the object would have a second template for parameter names, e.g. "up_${paramName}".) - Do we standardize on application id? This is a tricky issue -- I'm inclined to say that an app name is the same as a domain name, but that might be beyond the scope of 0.8 changes. - Should we use "{}" instead of "${}"? The latter is consistent with the current proposal for OpenSocial templates, but the former is consistent with a separate proposal for URI templates: < http://bitworking.org/news/URI_Templates>. - How long should the template live? Is it permanent, or can the container specify an expiration (again by returning an object)?
Or we can do something else entirely, but if people have strong objections, let's get another proposal on the table before the 18th.
--g
On Thu, Apr 10, 2008 at 9:29 AM, fern...@gmail.com <fern...@gmail.com> wrote:
> So did this thread just die? > Does anybody care about generating clean urls in a standard cross- > container manner?
> On Mar 27, 11:49 pm, "Nat Brown (ilike.com)" <nat...@gmail.com> wrote: > > There are a lot of painful implications to howrequestNavigateToworks > > within OpenSocial that should be addressed asap. Failure to fix these > > issues will hinder developers and business models on the platform. > > Here is my suggestion.
> > Currently applications emit at the server or rewrite on the client > > simple links into complicated javascript calls. For us in iLike, > > instead of generating:
> > Going through container javascript to navigate isn't the worst thing > > in the world, but the fact that there is no real URL in the browser > > has several perhaps non-obvious implications to the user experience, > > business model, and technical layering which are worth thinking about > > and fixing:
> > 1) when links are real HREF's in the browser, users can see where > > they are going when they hover over things, and they can copy/paste > > links and send them to friends. They can DIGG them, they can post them > > to facebook, they can copy them into google bookmarks. They can save > > them in their browser favorites. They can open links in new tabs. They > > can do none of these things in opensocial containers right now.
> > 2) Links to canvas pages from activity stream items and any kind of > > container notifications are also not going to work trivially -- gadget > > javascript is not involved, we need to embed specific links into > > activity streams, notifications, and messages. we can't do that right > > now.
> > 3) From a development perspective, the links are not only more > > readable for us and lead us to the code backing them more quickly, but > > we can also paste such links into our ticketing system and find and > > resolve issues more quickly rather than needed to create tickets that > > describe the steps to get to a sub-page. We can also concatenate > > suffixes from production links onto our private workspace or staging > > links to test out fixes. Partners can send us links that are broken or > > that they have a question about. Customers can point us at particular > > pages that have a problem, or our help buttons can automaticaly send > > us the page the user was on. We can use simple site performance and > > uptime monitoring tools to see how our opensocial application is > > performing if we have URLs. When we don't have real URLs in some > > fashion, all of this stops and our development process slows down and > > our customers and partners do not bother taking the time to send us > > feedback, or they are frustrated by the process, and we can't easily > > monitor the uptime or performance of our application from an end-user > > perspective. We get reports like "on the NNN artist page on Orkut > > there is a link to a concert on July 3rd at the Gorge amphitheatre..." > > we can ping our web cluster for basic uptime/performance, but we can't > > ping specific user or canvas pages to see whether something is broken. > > This makes developing for and supporting OpenSocial painful.
> > 4) Also from a development perspective, when we use real URLs a whole > > class of URL-signing and parameter-passing bugs that have plagued each > > container and which continue plaguing us daily here would have been > > eliminated or minimally easier to track down. Encoding & signing " " > > and "+" was broken. UTF8 characters like Mötley Crüe weren't working. > > All this because containers don't know exactly what to encode or how > > and are doing it within JSON blobs. It's unclear why this wheel of URL- > > encoding is being reinvented.
> > 5) if there are javascript errors anywhere on the page and javascript > > stops running, navigation simply breaks, which is a horrendous user > > experience. They can refresh, but they can't go anywhere within our > > content -- not good and makes our applications and opensocial feel > > flaky. This happens regularly.
> > 6) Finally from a business model perspective, real URLs give us the > > ability to create ads and external references that refer to our canvas > > pages. It allows us to cross-promote our applications and our canvas > > pages between different opensocial containers and facebook and our own > > sites. It allows applications to cross-link with one another within a > > containers, for promotional or other reasons. It allows us to email > > users and give them a link to visit Hi5, Orkut, or MySpace versions of > > iLike and add our application, and it allows us to do conversion- > > tracking for installs from ads or email pointers and to optimize our > > conversion to installation. We have none of this without URLs. The > > most trivial example of this kind of utility which opensocial recently > > lost traffic from is that we launched a new REM album for free > > streaming on 3/24 exclusively with iLike. We were able to point users, > > the press, record labels, and bands (including the band itself, REM) > > tohttp://apps.facebook.com/ilike/remand tohttp://www.ilike.com/rem. > > We have no URL to point press/analysts or the band to on Orkut, Hi5, > > MySpace. On REM's "artist dashboard" on ilike we can point them to > > their iLike-generated artist pages in non-OpenSocial containers so > > they can preview how the songs and videos they are posting will appear > > to their fans. We can't point them to their OpenSocial canvas pages.
> > You may think that this level of url cross-referencing is only useful > > to complex/deep apps with many canvas pages like ours. This is not the > > case -- even the smallest applications benefit from the business model > > and development implications of URLs that can fall back on pure > > navigation.
> > So, in a nutshell, here's the ideal API from my perspective: users can > > copy-paste the URLs and we can construct urls offline or server-side > > (given a known root, which ideally would > behttp://apps.<container>.com/ilike, > > but fine with us if it's anything fixed like http://<container>/app_100) > > and end up back in our application, but we actually > userequestNavigateTounder the covers which does all the good things > > containers apparently need in all the different contexts and we can > > support zany things like desktop/offline containers.
> > (the latter if the iframe host puts our docroot into place as they > > host our manifest, or we could do that ourselves given a fixed base > > URL)
> > Note that I would prefer this was shortened to take an URL instead of > > making us do all the path, options crud to indicate a GET -- this is > > just code that each application duplicates over and over again and we > > should optimize the most common case. If you couldn't do that we could > > stick with the longer convoluted arguments -- I don't really mind, > > though I think it creates an irritating barrier to entry for > > programmers to figure out for this API -- we would probably be > > rewriting this content on the client by looking for rel="nofollow" or > > some such on <a tags, like:
On Thu, Apr 10, 2008 at 10:32 AM, Graham Spencer <g...@google.com> wrote: > In keeping with the proposal for spec changes that Cassie just announced (+1 > on that BTW), let's make an official call for spec change on this topic.
> I'll officially propose what I informally proposed above: we should add JS > and RESTful API methods that allow apps to fetch a (long-lived) URL > template.
> This returns a string containing "${}" variables. The three supported > variables are: > - name: the name or id of the application > - path: an application-defined path string > - params: application-defined parameters, query-encoded.
> For discussion: > - Should we add other parameters, e.g. locale? > - Should we add configuration for parameter prefixing as proposed by Kevin? > (In that case containerUrlTemplate might return an object instead of just a > string, and the object would have a second template for parameter names, > e.g. "up_${paramName}".) > - Do we standardize on application id? This is a tricky issue -- I'm > inclined to say that an app name is the same as a domain name, but that > might be beyond the scope of 0.8 changes. > - Should we use "{}" instead of "${}"? The latter is consistent with the > current proposal for OpenSocial templates, but the former is consistent with > a separate proposal for URI templates: > <http://bitworking.org/news/URI_Templates>.
I also want to add that in addition, the API server will provide a service document to allow clients to discover the various endpoints available. http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.ht... Right now I'm assuming the three workspaces: people, activities and app data, but if the app data store is not the right place to store this info, maybe we could add another workspace with app urls. Navigating these docs can be a little heavy weight so maybe we could expose the methods we use to generate it for quicker json-rpc-like access.
> On Thu, Apr 10, 2008 at 10:32 AM, Graham Spencer <g...@google.com> wrote: > > In keeping with the proposal for spec changes that Cassie just announced > (+1 > > on that BTW), let's make an official call for spec change on this topic.
> > I'll officially propose what I informally proposed above: we should add > JS > > and RESTful API methods that allow apps to fetch a (long-lived) URL > > template.
> > This returns a string containing "${}" variables. The three supported > > variables are: > > - name: the name or id of the application > > - path: an application-defined path string > > - params: application-defined parameters, query-encoded.
> > For discussion: > > - Should we add other parameters, e.g. locale? > > - Should we add configuration for parameter prefixing as proposed by > Kevin? > > (In that case containerUrlTemplate might return an object instead of > just a > > string, and the object would have a second template for parameter names, > > e.g. "up_${paramName}".) > > - Do we standardize on application id? This is a tricky issue -- I'm > > inclined to say that an app name is the same as a domain name, but that > > might be beyond the scope of 0.8 changes. > > - Should we use "{}" instead of "${}"? The latter is consistent with the > > current proposal for OpenSocial templates, but the former is consistent > with > > a separate proposal for URI templates: > > <http://bitworking.org/news/URI_Templates>.
It is really not possible to statically enumerate the collections on, for example Person or Activity because many of the collections are defined based on the data available. For example, friends of FOO collection is defined when FOO is a valid Person. If the person doesn't exist, then a service document cannot include this collection - but it doesn't mean the collection won't exist in the future. Worse yet, the above collection may exist at the time of service document retrieval but may not exist after sometime, if FOO is no longer valid.
so, implementing service document retrieval is not really that useful. and it is not part of the proposal by John Panzer originally..
> <http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.ht...> > Right now I'm assuming the three workspaces: people, activities and > app data, but if the app data store is not the right place to store > this info, maybe we could add another workspace with app urls. > Navigating these docs can be a little heavy weight so maybe we could > expose the methods we use to generate it for quicker json-rpc-like > access.
> davep
> > - How long should the template live? Is it permanent, or can the > container > > specify an expiration (again by returning an object)?
> > Or we can do something else entirely, but if people have strong > objections, > > let's get another proposal on the table before the 18th.
On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com> wrote: > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer <david.prim...@gmail.com> > wrote: > > I don't know why OpenSocial chose ${} but I don't see a reason for a > > divergence from Joe's draft spec > > http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-03.txt
> It is really not possible to statically enumerate the collections on, for > example Person or Activity because many of the collections are defined based > on the data available. > For example, friends of FOO collection is defined when FOO is a valid > Person. If the person doesn't exist, then a service document cannot include > this collection - but it doesn't mean the collection won't exist in the > future. > Worse yet, the above collection may exist at the time of service document > retrieval but may not exist after sometime, if FOO is no longer valid.
> so, implementing service document retrieval is not really that useful. > and it is not part of the proposal by John Panzer originally..
Ok, so you're saying service docs don't work for dynamic web services, only simple static publishing? I think they're specified rather loosely and I haven't seen many non-trivial examples that would prove what you're saying. In the absence of a specific description format like OpenSearch, what about a WADL file?
Sorry this is getting a little off topic from the proposed URI template RPC.
> > Right now I'm assuming the three workspaces: people, activities and > > app data, but if the app data store is not the right place to store > > this info, maybe we could add another workspace with app urls. > > Navigating these docs can be a little heavy weight so maybe we could > > expose the methods we use to generate it for quicker json-rpc-like > > access.
> > davep
> > > - How long should the template live? Is it permanent, or can the > container > > > specify an expiration (again by returning an object)?
> > > Or we can do something else entirely, but if people have strong > objections, > > > let's get another proposal on the table before the 18th.
> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com> > wrote: > > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer <david.prim...@gmail.com
> > > I also want to add that in addition, the API server will provide a > > > service document to allow clients to discover the various endpoints > > > available.
> > It is really not possible to statically enumerate the collections on, > for > > example Person or Activity because many of the collections are defined > based > > on the data available. > > For example, friends of FOO collection is defined when FOO is a valid > > Person. If the person doesn't exist, then a service document cannot > include > > this collection - but it doesn't mean the collection won't exist in the > > future. > > Worse yet, the above collection may exist at the time of service > document > > retrieval but may not exist after sometime, if FOO is no longer valid.
> > so, implementing service document retrieval is not really that useful. > > and it is not part of the proposal by John Panzer originally..
> Ok, so you're saying service docs don't work for dynamic web services, > only simple static publishing? I think they're specified rather > loosely and I haven't seen many non-trivial examples that would prove > what you're saying. In the absence of a specific description format > like OpenSearch, what about a WADL file?
we need dynamic discovery of resources (workspaces, collections), in the absence of a "reliable" service document. By that I mean, a mechanism to discover the URLs for resources - not templates, but complete and accurate URLs. Don't know of any such mechanism available right now. No agreement on WADL in the community yet.
> Sorry this is getting a little off topic from the proposed URI template > RPC.
> davep
> > > Right now I'm assuming the three workspaces: people, activities and > > > app data, but if the app data store is not the right place to store > > > this info, maybe we could add another workspace with app urls. > > > Navigating these docs can be a little heavy weight so maybe we could > > > expose the methods we use to generate it for quicker json-rpc-like > > > access.
> > > davep
> > > > - How long should the template live? Is it permanent, or can the > > container > > > > specify an expiration (again by returning an object)?
> > > > Or we can do something else entirely, but if people have strong > > objections, > > > > let's get another proposal on the table before the 18th.
Okay - going back to the js apis for a moment. Graham suggested a container url template approach. I would like to propose an additional solution:
/** * Returns a url for navigating to the current app on the given surface. Will include the path and parameters in the url. Similar to requestNavigateTo. * * @param {gadgets.views.View} view The view to navigate to * @param {String} path The path to navigate to * @param {Map.<String, String>} opt_params Parameters to pass to the * gadget after it has been navigated to on the surface * * @return {String} a url that can be used by the gadget * @member opensocial */ gadgets.views.getUrlFor = function(surface, path, opt_params) {};
So, for 0.8 would we rather:
1. Add a method to fetch a url template from the container. This would be what Graham proposed (except it might fit better on the gadgets.views object instead of opensocial) or 2. Add a method to get a url for a given surface, path and set of params. (The method right above)
On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> wrote:
> On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <david.prim...@gmail.com> > wrote:
>> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com> >> wrote: >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer >> > <david.prim...@gmail.com> >> > wrote: >> > > I don't know why OpenSocial chose ${} but I don't see a reason for a >> > > divergence from Joe's draft spec >> > > http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-03.txt
>> > > I also want to add that in addition, the API server will provide a >> > > service document to allow clients to discover the various endpoints >> > > available.
>> > It is really not possible to statically enumerate the collections on, >> > for >> > example Person or Activity because many of the collections are defined >> > based >> > on the data available. >> > For example, friends of FOO collection is defined when FOO is a valid >> > Person. If the person doesn't exist, then a service document cannot >> > include >> > this collection - but it doesn't mean the collection won't exist in the >> > future. >> > Worse yet, the above collection may exist at the time of service >> > document >> > retrieval but may not exist after sometime, if FOO is no longer valid.
>> > so, implementing service document retrieval is not really that useful. >> > and it is not part of the proposal by John Panzer originally..
>> Ok, so you're saying service docs don't work for dynamic web services, >> only simple static publishing? I think they're specified rather >> loosely and I haven't seen many non-trivial examples that would prove >> what you're saying. In the absence of a specific description format >> like OpenSearch, what about a WADL file?
> we need dynamic discovery of resources (workspaces, collections), in the > absence of a "reliable" service document. > By that I mean, a mechanism to discover the URLs for resources - not > templates, but complete and accurate URLs. > Don't know of any such mechanism available right now. No agreement on WADL > in the community yet.
>> Sorry this is getting a little off topic from the proposed URI template >> RPC.
>> davep
>> > > Right now I'm assuming the three workspaces: people, activities and >> > > app data, but if the app data store is not the right place to store >> > > this info, maybe we could add another workspace with app urls. >> > > Navigating these docs can be a little heavy weight so maybe we could >> > > expose the methods we use to generate it for quicker json-rpc-like >> > > access.
>> > > davep
>> > > > - How long should the template live? Is it permanent, or can the >> > container >> > > > specify an expiration (again by returning an object)?
>> > > > Or we can do something else entirely, but if people have strong >> > objections, >> > > > let's get another proposal on the table before the 18th.
> Okay - going back to the js apis for a moment. Graham suggested a
> container url template approach. I would like to propose an additional
> solution:
> /**
> * Returns a url for navigating to the current app on the given
> surface. Will include the path and parameters in the url. Similar to
> requestNavigateTo.
> *
> * @param {gadgets.views.View} view The view to navigate to
> * @param {String} path The path to navigate to
> * @param {Map.<String, String>} opt_params Parameters to pass to the
> * gadget after it has been navigated to on the surface
> *
> * @return {String} a url that can be used by the gadget
> * @member opensocial
> */
> gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> So, for 0.8 would we rather:
> 1. Add a method to fetch a url template from the container. This would
> be what Graham proposed (except it might fit better on the
> gadgets.views object instead of opensocial) or
> 2. Add a method to get a url for a given surface, path and set of
> params. (The method right above)
> Please vote or suggest other proposals.
> Thanks!
> - CassieOn Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> wrote:
> > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <david.prim...@gmail.com>
> > wrote:
> >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com>
> >> wrote:
> >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer
> >> > <david.prim...@gmail.com>
> >> > wrote:
> >> > > I don't know why OpenSocial chose ${} but I don't see a reason for a
> >> > > divergence from Joe's draft spec
> >> > >http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-03.txt
> >> > > I also want to add that in addition, the API server will provide a
> >> > > service document to allow clients to discover the various endpoints
> >> > > available.
> >> > It is really not possible to statically enumerate the collections on,
> >> > for
> >> > example Person or Activity because many of the collections are defined
> >> > based
> >> > on the data available.
> >> > For example, friends of FOO collection is defined when FOO is a valid
> >> > Person. If the person doesn't exist, then a service document cannot
> >> > include
> >> > this collection - but it doesn't mean the collection won't exist in the
> >> > future.
> >> > Worse yet, the above collection may exist at the time of service
> >> > document
> >> > retrieval but may not exist after sometime, if FOO is no longer valid.
> >> > so, implementing service document retrieval is not really that useful.
> >> > and it is not part of the proposal by John Panzer originally..
> >> Ok, so you're saying service docs don't work for dynamic web services,
> >> only simple static publishing? I think they're specified rather
> >> loosely and I haven't seen many non-trivial examples that would prove
> >> what you're saying. In the absence of a specific description format
> >> like OpenSearch, what about a WADL file?
> > we need dynamic discovery of resources (workspaces, collections), in the
> > absence of a "reliable" service document.
> > By that I mean, a mechanism to discover the URLs for resources - not
> > templates, but complete and accurate URLs.
> > Don't know of any such mechanism available right now. No agreement on WADL
> > in the community yet.
> >> Sorry this is getting a little off topic from the proposed URI template
> >> RPC.
> >> davep
> >> > > Right now I'm assuming the three workspaces: people, activities and
> >> > > app data, but if the app data store is not the right place to store
> >> > > this info, maybe we could add another workspace with app urls.
> >> > > Navigating these docs can be a little heavy weight so maybe we could
> >> > > expose the methods we use to generate it for quicker json-rpc-like
> >> > > access.
> >> > > davep
> >> > > > - How long should the template live? Is it permanent, or can the
> >> > container
> >> > > > specify an expiration (again by returning an object)?
> >> > > > Or we can do something else entirely, but if people have strong
> >> > objections,
> >> > > > let's get another proposal on the table before the 18th.
The main reason I had proposed the container URL template approach was so that developers could quickly and easily generate URLs on their own servers without having to make either JS or RESTful API calls (except maybe once the first time).
So I like the idea of having a JS function that actually generates the URL, but I don't think it's sufficient if we want server-side URLs to be easy to create. Cassie -- do you have thoughts or suggestions about the server-side URL issue?
On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> Okay - going back to the js apis for a moment. Graham suggested a > container url template approach. I would like to propose an additional > solution:
> /** > * Returns a url for navigating to the current app on the given > surface. Will include the path and parameters in the url. Similar to > requestNavigateTo. > * > * @param {gadgets.views.View} view The view to navigate to > * @param {String} path The path to navigate to > * @param {Map.<String, String>} opt_params Parameters to pass to the > * gadget after it has been navigated to on the surface > * > * @return {String} a url that can be used by the gadget > * @member opensocial > */ > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> So, for 0.8 would we rather:
> 1. Add a method to fetch a url template from the container. This would > be what Graham proposed (except it might fit better on the > gadgets.views object instead of opensocial) or > 2. Add a method to get a url for a given surface, path and set of > params. (The method right above)
> Please vote or suggest other proposals.
> Thanks!
> - Cassie
> On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> wrote:
> > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <david.prim...@gmail.com
> > wrote:
> >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com> > >> wrote: > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer > >> > <david.prim...@gmail.com> > >> > wrote: > >> > > I don't know why OpenSocial chose ${} but I don't see a reason for a > >> > > divergence from Joe's draft spec
> >> > > I also want to add that in addition, the API server will provide a > >> > > service document to allow clients to discover the various endpoints > >> > > available.
> >> > It is really not possible to statically enumerate the collections on, > >> > for > >> > example Person or Activity because many of the collections are defined > >> > based > >> > on the data available. > >> > For example, friends of FOO collection is defined when FOO is a valid > >> > Person. If the person doesn't exist, then a service document cannot > >> > include > >> > this collection - but it doesn't mean the collection won't exist in > the > >> > future. > >> > Worse yet, the above collection may exist at the time of service > >> > document > >> > retrieval but may not exist after sometime, if FOO is no longer valid.
> >> > so, implementing service document retrieval is not really that useful. > >> > and it is not part of the proposal by John Panzer originally..
> >> Ok, so you're saying service docs don't work for dynamic web services, > >> only simple static publishing? I think they're specified rather > >> loosely and I haven't seen many non-trivial examples that would prove > >> what you're saying. In the absence of a specific description format > >> like OpenSearch, what about a WADL file?
> > we need dynamic discovery of resources (workspaces, collections), in the > > absence of a "reliable" service document. > > By that I mean, a mechanism to discover the URLs for resources - not > > templates, but complete and accurate URLs. > > Don't know of any such mechanism available right now. No agreement on > WADL > > in the community yet.
> >> Sorry this is getting a little off topic from the proposed URI template > >> RPC.
> >> davep
> >> > > Right now I'm assuming the three workspaces: people, activities and > >> > > app data, but if the app data store is not the right place to store > >> > > this info, maybe we could add another workspace with app urls. > >> > > Navigating these docs can be a little heavy weight so maybe we could > >> > > expose the methods we use to generate it for quicker json-rpc-like > >> > > access.
> >> > > davep
> >> > > > - How long should the template live? Is it permanent, or can the > >> > container > >> > > > specify an expiration (again by returning an object)?
> >> > > > Or we can do something else entirely, but if people have strong > >> > objections, > >> > > > let's get another proposal on the table before the 18th.
I agree with Graham -- being able to pre-generate urls is very important, especially when the data is ultimately fetched over HTTP and can't take advantage of templating mechanisms and the like. My chief concern is ensuring that the url generation scheme is sound.
On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> wrote: > The main reason I had proposed the container URL template approach was so > that developers could quickly and easily generate URLs on their own servers > without having to make either JS or RESTful API calls (except maybe once the > first time).
> So I like the idea of having a JS function that actually generates the > URL, but I don't think it's sufficient if we want server-side URLs to be > easy to create. Cassie -- do you have thoughts or suggestions about the > server-side URL issue?
> --g
> On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> > Okay - going back to the js apis for a moment. Graham suggested a > > container url template approach. I would like to propose an additional > > solution:
> > /** > > * Returns a url for navigating to the current app on the given > > surface. Will include the path and parameters in the url. Similar to > > requestNavigateTo. > > * > > * @param {gadgets.views.View} view The view to navigate to > > * @param {String} path The path to navigate to > > * @param {Map.<String, String>} opt_params Parameters to pass to > > the > > * gadget after it has been navigated to on the surface > > * > > * @return {String} a url that can be used by the gadget > > * @member opensocial > > */ > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> > So, for 0.8 would we rather:
> > 1. Add a method to fetch a url template from the container. This would > > be what Graham proposed (except it might fit better on the > > gadgets.views object instead of opensocial) or > > 2. Add a method to get a url for a given surface, path and set of > > params. (The method right above)
> > Please vote or suggest other proposals.
> > Thanks!
> > - Cassie
> > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> > > wrote:
> > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer < > > david.prim...@gmail.com> > > > wrote:
> > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com> > > >> wrote: > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer > > >> > <david.prim...@gmail.com> > > >> > wrote: > > >> > > I don't know why OpenSocial chose ${} but I don't see a reason > > for a > > >> > > divergence from Joe's draft spec
> > >> > > I also want to add that in addition, the API server will provide > > a > > >> > > service document to allow clients to discover the various > > endpoints > > >> > > available.
> > >> > It is really not possible to statically enumerate the collections > > on, > > >> > for > > >> > example Person or Activity because many of the collections are > > defined > > >> > based > > >> > on the data available. > > >> > For example, friends of FOO collection is defined when FOO is a > > valid > > >> > Person. If the person doesn't exist, then a service document cannot > > >> > include > > >> > this collection - but it doesn't mean the collection won't exist in > > the > > >> > future. > > >> > Worse yet, the above collection may exist at the time of service > > >> > document > > >> > retrieval but may not exist after sometime, if FOO is no longer > > valid.
> > >> > so, implementing service document retrieval is not really that > > useful. > > >> > and it is not part of the proposal by John Panzer originally..
> > >> Ok, so you're saying service docs don't work for dynamic web > > services, > > >> only simple static publishing? I think they're specified rather > > >> loosely and I haven't seen many non-trivial examples that would prove > > >> what you're saying. In the absence of a specific description format > > >> like OpenSearch, what about a WADL file?
> > > we need dynamic discovery of resources (workspaces, collections), in > > the > > > absence of a "reliable" service document. > > > By that I mean, a mechanism to discover the URLs for resources - not > > > templates, but complete and accurate URLs. > > > Don't know of any such mechanism available right now. No agreement on > > WADL > > > in the community yet.
> > >> Sorry this is getting a little off topic from the proposed URI > > template > > >> RPC.
> > >> davep
> > >> > > Right now I'm assuming the three workspaces: people, activities > > and > > >> > > app data, but if the app data store is not the right place to > > store > > >> > > this info, maybe we could add another workspace with app urls. > > >> > > Navigating these docs can be a little heavy weight so maybe we > > could > > >> > > expose the methods we use to generate it for quicker > > json-rpc-like > > >> > > access.
> > >> > > davep
> > >> > > > - How long should the template live? Is it permanent, or can > > the > > >> > container > > >> > > > specify an expiration (again by returning an object)?
> > >> > > > Or we can do something else entirely, but if people have strong > > >> > objections, > > >> > > > let's get another proposal on the table before the 18th.
+1 from LinkedIn. Especially when it comes to embedded links to canvas
pages in activity feeds. We had discussed making our own ${canvas_url}
token and do replacement on our servers, but we know developers are
going to want to generate these URLs on their own servers. Basically
points 2 & 6 that Nat made in the original post.
-Brandon
On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote:
> I agree with Graham -- being able to pre-generate urls is very important,
> especially when the data is ultimately fetched over HTTP and can't take
> advantage of templating mechanisms and the like. My chief concern is
> ensuring that the url generation scheme is sound.
> On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> wrote:
> > The main reason I had proposed the container URL template approach was so
> > that developers could quickly and easily generate URLs on their own servers
> > without having to make either JS or RESTful API calls (except maybe once the
> > first time).
> > So I like the idea of having a JS function that actually generates the
> > URL, but I don't think it's sufficient if we want server-side URLs to be
> > easy to create. Cassie -- do you have thoughts or suggestions about the
> > server-side URL issue?
> > --g
> > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> > > Okay - going back to the js apis for a moment. Graham suggested a
> > > container url template approach. I would like to propose an additional
> > > solution:
> > > /**
> > > * Returns a url for navigating to the current app on the given
> > > surface. Will include the path and parameters in the url. Similar to
> > > requestNavigateTo.
> > > *
> > > * @param {gadgets.views.View} view The view to navigate to
> > > * @param {String} path The path to navigate to
> > > * @param {Map.<String, String>} opt_params Parameters to pass to
> > > the
> > > * gadget after it has been navigated to on the surface
> > > *
> > > * @return {String} a url that can be used by the gadget
> > > * @member opensocial
> > > */
> > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> > > So, for 0.8 would we rather:
> > > 1. Add a method to fetch a url template from the container. This would
> > > be what Graham proposed (except it might fit better on the
> > > gadgets.views object instead of opensocial) or
> > > 2. Add a method to get a url for a given surface, path and set of
> > > params. (The method right above)
> > > Please vote or suggest other proposals.
> > > Thanks!
> > > - Cassie
> > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com>
> > > wrote:
> > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <
> > > david.prim...@gmail.com>
> > > > wrote:
> > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <vasun...@gmail.com>
> > > >> wrote:
> > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer
> > > >> > <david.prim...@gmail.com>
> > > >> > wrote:
> > > >> > > I don't know why OpenSocial chose ${} but I don't see a reason
> > > for a
> > > >> > > divergence from Joe's draft spec
> > > >> > > I also want to add that in addition, the API server will provide
> > > a
> > > >> > > service document to allow clients to discover the various
> > > endpoints
> > > >> > > available.
> > > >> > It is really not possible to statically enumerate the collections
> > > on,
> > > >> > for
> > > >> > example Person or Activity because many of the collections are
> > > defined
> > > >> > based
> > > >> > on the data available.
> > > >> > For example, friends of FOO collection is defined when FOO is a
> > > valid
> > > >> > Person. If the person doesn't exist, then a service document cannot
> > > >> > include
> > > >> > this collection - but it doesn't mean the collection won't exist in
> > > the
> > > >> > future.
> > > >> > Worse yet, the above collection may exist at the time of service
> > > >> > document
> > > >> > retrieval but may not exist after sometime, if FOO is no longer
> > > valid.
> > > >> > so, implementing service document retrieval is not really that
> > > useful.
> > > >> > and it is not part of the proposal by John Panzer originally..
> > > >> Ok, so you're saying service docs don't work for dynamic web
> > > services,
> > > >> only simple static publishing? I think they're specified rather
> > > >> loosely and I haven't seen many non-trivial examples that would prove
> > > >> what you're saying. In the absence of a specific description format
> > > >> like OpenSearch, what about a WADL file?
> > > > we need dynamic discovery of resources (workspaces, collections), in
> > > the
> > > > absence of a "reliable" service document.
> > > > By that I mean, a mechanism to discover the URLs for resources - not
> > > > templates, but complete and accurate URLs.
> > > > Don't know of any such mechanism available right now. No agreement on
> > > WADL
> > > > in the community yet.
> > > >> Sorry this is getting a little off topic from the proposed URI
> > > template
> > > >> RPC.
> > > >> davep
> > > >> > > Right now I'm assuming the three workspaces: people, activities
> > > and
> > > >> > > app data, but if the app data store is not the right place to
> > > store
> > > >> > > this info, maybe we could add another workspace with app urls.
> > > >> > > Navigating these docs can be a little heavy weight so maybe we
> > > could
> > > >> > > expose the methods we use to generate it for quicker
> > > json-rpc-like
> > > >> > > access.
> > > >> > > davep
> > > >> > > > - How long should the template live? Is it permanent, or can
> > > the
> > > >> > container
> > > >> > > > specify an expiration (again by returning an object)?
> > > >> > > > Or we can do something else entirely, but if people have strong
> > > >> > objections,
> > > >> > > > let's get another proposal on the table before the 18th.
This returns a string containing "${}" variables. The four supported variables are: - name: the name or id of the application - owner: the id of the owner of the page - path: an application-defined path string - params: application-defined parameters, query-encoded.
On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com> wrote:
> +1 from LinkedIn. Especially when it comes to embedded links to canvas > pages in activity feeds. We had discussed making our own ${canvas_url} > token and do replacement on our servers, but we know developers are > going to want to generate these URLs on their own servers. Basically > points 2 & 6 that Nat made in the original post.
> -Brandon
> On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote: > > I agree with Graham -- being able to pre-generate urls is very important, > > especially when the data is ultimately fetched over HTTP and can't take > > advantage of templating mechanisms and the like. My chief concern is > > ensuring that the url generation scheme is sound.
> > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> > wrote: > > > The main reason I had proposed the container URL template approach was > so > > > that developers could quickly and easily generate URLs on their own > servers > > > without having to make either JS or RESTful API calls (except maybe > once the > > > first time).
> > > So I like the idea of having a JS function that actually generates the > > > URL, but I don't think it's sufficient if we want server-side URLs to > be > > > easy to create. Cassie -- do you have thoughts or suggestions about the > > > server-side URL issue?
> > > --g
> > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> > > > Okay - going back to the js apis for a moment. Graham suggested a > > > > container url template approach. I would like to propose an > additional > > > > solution:
> > > > /** > > > > * Returns a url for navigating to the current app on the given > > > > surface. Will include the path and parameters in the url. Similar to > > > > requestNavigateTo. > > > > * > > > > * @param {gadgets.views.View} view The view to navigate to > > > > * @param {String} path The path to navigate to > > > > * @param {Map.<String, String>} opt_params Parameters to pass > to > > > > the > > > > * gadget after it has been navigated to on the surface > > > > * > > > > * @return {String} a url that can be used by the gadget > > > > * @member opensocial > > > > */ > > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> > > > So, for 0.8 would we rather:
> > > > 1. Add a method to fetch a url template from the container. This > would > > > > be what Graham proposed (except it might fit better on the > > > > gadgets.views object instead of opensocial) or > > > > 2. Add a method to get a url for a given surface, path and set of > > > > params. (The method right above)
> > > > Please vote or suggest other proposals.
> > > > Thanks!
> > > > - Cassie
> > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> > > > > wrote:
> > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer < > > > > david.prim...@gmail.com> > > > > > wrote:
> > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori < > vasun...@gmail.com> > > > > >> wrote: > > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer > > > > >> > <david.prim...@gmail.com> > > > > >> > wrote: > > > > >> > > I don't know why OpenSocial chose ${} but I don't see a reason > > > > for a > > > > >> > > divergence from Joe's draft spec
> > > > >> > > I also want to add that in addition, the API server will > provide > > > > a > > > > >> > > service document to allow clients to discover the various > > > > endpoints > > > > >> > > available.
> > > > >> > It is really not possible to statically enumerate the > collections > > > > on, > > > > >> > for > > > > >> > example Person or Activity because many of the collections are > > > > defined > > > > >> > based > > > > >> > on the data available. > > > > >> > For example, friends of FOO collection is defined when FOO is a > > > > valid > > > > >> > Person. If the person doesn't exist, then a service document > cannot > > > > >> > include > > > > >> > this collection - but it doesn't mean the collection won't exist > in > > > > the > > > > >> > future. > > > > >> > Worse yet, the above collection may exist at the time of > service > > > > >> > document > > > > >> > retrieval but may not exist after sometime, if FOO is no longer > > > > valid.
> > > > >> > so, implementing service document retrieval is not really that > > > > useful. > > > > >> > and it is not part of the proposal by John Panzer originally..
> > > > >> Ok, so you're saying service docs don't work for dynamic web > > > > services, > > > > >> only simple static publishing? I think they're specified rather > > > > >> loosely and I haven't seen many non-trivial examples that would > prove > > > > >> what you're saying. In the absence of a specific description > format > > > > >> like OpenSearch, what about a WADL file?
> > > > > we need dynamic discovery of resources (workspaces, collections), > in > > > > the > > > > > absence of a "reliable" service document. > > > > > By that I mean, a mechanism to discover the URLs for resources - > not > > > > > templates, but complete and accurate URLs. > > > > > Don't know of any such mechanism available right now. No agreement > on > > > > WADL > > > > > in the community yet.
> > > > >> Sorry this is getting a little off topic from the proposed URI > > > > template > > > > >> RPC.
> > > > >> davep
> > > > >> > > Right now I'm assuming the three workspaces: people, > activities > > > > and > > > > >> > > app data, but if the app data store is not the right place to > > > > store > > > > >> > > this info, maybe we could add another workspace with app urls. > > > > >> > > Navigating these docs can be a little heavy weight so maybe we > > > > could > > > > >> > > expose the methods we use to generate it for quicker > > > > json-rpc-like > > > > >> > > access.
> > > > >> > > davep
> > > > >> > > > - How long should the template live? Is it permanent, or > can > > > > the > > > > >> > container > > > > >> > > > specify an expiration (again by returning an object)?
> > > > >> > > > Or we can do something else entirely, but if people have > strong > > > > >> > objections, > > > > >> > > > let's get another proposal on the table before the 18th.
I'm tentatively +1 on this, but wanted to clarify a couple questions:
How explicit can the spec be about defining what should be pointed to
by such URLs? We can't specify a view name like "canvas", but can the
wording be something like "should navigate to a view where the
application corresponding to ${name} is featured prominently on the
page?"
It appears that some parameters are optional... for example, "http://
apps.container.com/${name}#${path}?${params} " doesn't include $
{owner}. Which parameters are optional? What happens if a container
returns something like "http://apps.container.com/person/${owner}"??
~Arne
On Apr 21, 4:13 am, Cassie <d...@google.com> wrote:
> This returns a string containing "${}" variables. The four supported
> variables are:
> - name: the name or id of the application
> - owner: the id of the owner of the page
> - path: an application-defined path string
> - params: application-defined parameters, query-encoded.
> I -think- we have +1s from kevin, graham, brandon, and fernman.
> If this is right and we get one more person to +1 then it is good to go.
> - Cassie
> On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com> wrote:
> > +1 from LinkedIn. Especially when it comes to embedded links to canvas
> > pages in activity feeds. We had discussed making our own ${canvas_url}
> > token and do replacement on our servers, but we know developers are
> > going to want to generate these URLs on their own servers. Basically
> > points 2 & 6 that Nat made in the original post.
> > -Brandon
> > On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote:
> > > I agree with Graham -- being able to pre-generate urls is very important,
> > > especially when the data is ultimately fetched over HTTP and can't take
> > > advantage of templating mechanisms and the like. My chief concern is
> > > ensuring that the url generation scheme is sound.
> > > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com>
> > wrote:
> > > > The main reason I had proposed the container URL template approach was
> > so
> > > > that developers could quickly and easily generate URLs on their own
> > servers
> > > > without having to make either JS or RESTful API calls (except maybe
> > once the
> > > > first time).
> > > > So I like the idea of having a JS function that actually generates the
> > > > URL, but I don't think it's sufficient if we want server-side URLs to
> > be
> > > > easy to create. Cassie -- do you have thoughts or suggestions about the
> > > > server-side URL issue?
> > > > --g
> > > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> > > > > Okay - going back to the js apis for a moment. Graham suggested a
> > > > > container url template approach. I would like to propose an
> > additional
> > > > > solution:
> > > > > /**
> > > > > * Returns a url for navigating to the current app on the given
> > > > > surface. Will include the path and parameters in the url. Similar to
> > > > > requestNavigateTo.
> > > > > *
> > > > > * @param {gadgets.views.View} view The view to navigate to
> > > > > * @param {String} path The path to navigate to
> > > > > * @param {Map.<String, String>} opt_params Parameters to pass
> > to
> > > > > the
> > > > > * gadget after it has been navigated to on the surface
> > > > > *
> > > > > * @return {String} a url that can be used by the gadget
> > > > > * @member opensocial
> > > > > */
> > > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> > > > > So, for 0.8 would we rather:
> > > > > 1. Add a method to fetch a url template from the container. This
> > would
> > > > > be what Graham proposed (except it might fit better on the
> > > > > gadgets.views object instead of opensocial) or
> > > > > 2. Add a method to get a url for a given surface, path and set of
> > > > > params. (The method right above)
> > > > > Please vote or suggest other proposals.
> > > > > Thanks!
> > > > > - Cassie
> > > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com>
> > > > > wrote:
> > > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <
> > > > > david.prim...@gmail.com>
> > > > > > wrote:
> > > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <
> > vasun...@gmail.com>
> > > > > >> wrote:
> > > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer
> > > > > >> > <david.prim...@gmail.com>
> > > > > >> > wrote:
> > > > > >> > > I don't know why OpenSocial chose ${} but I don't see a reason
> > > > > for a
> > > > > >> > > divergence from Joe's draft spec
> > > > > >> > > I also want to add that in addition, the API server will
> > provide
> > > > > a
> > > > > >> > > service document to allow clients to discover the various
> > > > > endpoints
> > > > > >> > > available.
> > > > > >> > It is really not possible to statically enumerate the
> > collections
> > > > > on,
> > > > > >> > for
> > > > > >> > example Person or Activity because many of the collections are
> > > > > defined
> > > > > >> > based
> > > > > >> > on the data available.
> > > > > >> > For example, friends of FOO collection is defined when FOO is a
> > > > > valid
> > > > > >> > Person. If the person doesn't exist, then a service document
> > cannot
> > > > > >> > include
> > > > > >> > this collection - but it doesn't mean the collection won't exist
> > in
> > > > > the
> > > > > >> > future.
> > > > > >> > Worse yet, the above collection may exist at the time of
> > service
> > > > > >> > document
> > > > > >> > retrieval but may not exist after sometime, if FOO is no longer
> > > > > valid.
> > > > > >> > so, implementing service document retrieval is not really that
> > > > > useful.
> > > > > >> > and it is not part of the proposal by John Panzer originally..
> > > > > >> Ok, so you're saying service docs don't work for dynamic web
> > > > > services,
> > > > > >> only simple static publishing? I think they're specified rather
> > > > > >> loosely and I haven't seen many non-trivial examples that would
> > prove
> > > > > >> what you're saying. In the absence of a specific description
> > format
> > > > > >> like OpenSearch, what about a WADL file?
> > > > > > we need dynamic discovery of resources (workspaces, collections),
> > in
> > > > > the
> > > > > > absence of a "reliable" service document.
> > > > > > By that I mean, a mechanism to discover the URLs for resources -
> > not
> > > > > > templates, but complete and accurate URLs.
> > > > > > Don't know of any such mechanism available right now. No agreement
> > on
> > > > > WADL
> > > > > > in the community yet.
> > > > > >> Sorry this is getting a little off topic from the proposed URI
> > > > > template
> > > > > >> RPC.
> > > > > >> davep
> > > > > >> > > Right now I'm assuming the three workspaces: people,
> > activities
> > > > > and
> > > > > >> > > app data, but if the app data store is not the right place to
> > > > > store
> > > > > >> > > this info, maybe we could add another workspace with app urls.
> > > > > >> > > Navigating these docs can be a little heavy weight so maybe we
> > > > > could
> > > > > >> > > expose the methods we use to generate it for quicker
> > > > > json-rpc-like
> > > > > >> > > access.
> > > > > >> > > davep
> > > > > >> > > > - How long should the template live? Is it permanent, or
> > can
> > > > > the
> > > > > >> > container
> > > > > >> > > > specify an expiration (again by returning an object)?
> > > > > >> > > > Or we can do something else entirely, but if people have
> > strong
> > > > > >> > objections,
> > > > > >> > > > let's get another proposal on the table before the 18th.
Im also a tentative +1 here but I think some details need to be worked out before committing
Is the existing mechanism of extracting parentURL from the URL params using the gadgets.util fine for app developers to access the 'path' variable information?
Which id's are we talking about here. This may be a problem unique to Orkut but we have used a different id space for opensocial than the one we use for our URLs, open social owner id != page owner id. I'm loath to propose modifying the spec to include a NAVIGATION_ID to resolve this issue but...
'params' are currently exposed as JSON objects in gadgets js, are we proposing changing this to query encoded and have apps accommodate the associated change in structure this implies?
What rules do we expect containers to enforce about the naming conventions of params. Most containers are likely to have a diverse though small set of always reserved params. Does the spec need to say something about this?
On Mon, Apr 21, 2008 at 4:13 AM, Cassie <d...@google.com> wrote: > Okay, container templates it is. So, for a proposal like this: > (I included an owner param)
> This returns a string containing "${}" variables. The four supported > variables are: > - name: the name or id of the application > - owner: the id of the owner of the page > - path: an application-defined path string > - params: application-defined parameters, query-encoded.
> I -think- we have +1s from kevin, graham, brandon, and fernman. > If this is right and we get one more person to +1 then it is good to go.
> - Cassie
> On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com> wrote:
>> +1 from LinkedIn. Especially when it comes to embedded links to canvas >> pages in activity feeds. We had discussed making our own ${canvas_url} >> token and do replacement on our servers, but we know developers are >> going to want to generate these URLs on their own servers. Basically >> points 2 & 6 that Nat made in the original post.
>> -Brandon
>> On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote: >> > I agree with Graham -- being able to pre-generate urls is very >> important, >> > especially when the data is ultimately fetched over HTTP and can't take >> > advantage of templating mechanisms and the like. My chief concern is >> > ensuring that the url generation scheme is sound.
>> > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> >> wrote: >> > > The main reason I had proposed the container URL template approach was >> so >> > > that developers could quickly and easily generate URLs on their own >> servers >> > > without having to make either JS or RESTful API calls (except maybe >> once the >> > > first time).
>> > > So I like the idea of having a JS function that actually generates the >> > > URL, but I don't think it's sufficient if we want server-side URLs to >> be >> > > easy to create. Cassie -- do you have thoughts or suggestions about >> the >> > > server-side URL issue?
>> > > --g
>> > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
>> > > > Okay - going back to the js apis for a moment. Graham suggested a >> > > > container url template approach. I would like to propose an >> additional >> > > > solution:
>> > > > /** >> > > > * Returns a url for navigating to the current app on the given >> > > > surface. Will include the path and parameters in the url. Similar to >> > > > requestNavigateTo. >> > > > * >> > > > * @param {gadgets.views.View} view The view to navigate to >> > > > * @param {String} path The path to navigate to >> > > > * @param {Map.<String, String>} opt_params Parameters to pass >> to >> > > > the >> > > > * gadget after it has been navigated to on the surface >> > > > * >> > > > * @return {String} a url that can be used by the gadget >> > > > * @member opensocial >> > > > */ >> > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
>> > > > So, for 0.8 would we rather:
>> > > > 1. Add a method to fetch a url template from the container. This >> would >> > > > be what Graham proposed (except it might fit better on the >> > > > gadgets.views object instead of opensocial) or >> > > > 2. Add a method to get a url for a given surface, path and set of >> > > > params. (The method right above)
>> > > > Please vote or suggest other proposals.
>> > > > Thanks!
>> > > > - Cassie
>> > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com> >> > > > wrote:
>> > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer < >> > > > david.prim...@gmail.com> >> > > > > wrote:
>> > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori < >> vasun...@gmail.com> >> > > > >> wrote: >> > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer >> > > > >> > <david.prim...@gmail.com> >> > > > >> > wrote: >> > > > >> > > I don't know why OpenSocial chose ${} but I don't see a >> reason >> > > > for a >> > > > >> > > divergence from Joe's draft spec
>> > > > >> > > I also want to add that in addition, the API server will >> provide >> > > > a >> > > > >> > > service document to allow clients to discover the various >> > > > endpoints >> > > > >> > > available.
>> > > > >> > It is really not possible to statically enumerate the >> collections >> > > > on, >> > > > >> > for >> > > > >> > example Person or Activity because many of the collections are >> > > > defined >> > > > >> > based >> > > > >> > on the data available. >> > > > >> > For example, friends of FOO collection is defined when FOO is a >> > > > valid >> > > > >> > Person. If the person doesn't exist, then a service document >> cannot >> > > > >> > include >> > > > >> > this collection - but it doesn't mean the collection won't >> exist in >> > > > the >> > > > >> > future. >> > > > >> > Worse yet, the above collection may exist at the time of >> service >> > > > >> > document >> > > > >> > retrieval but may not exist after sometime, if FOO is no longer >> > > > valid.
>> > > > >> > so, implementing service document retrieval is not really that >> > > > useful. >> > > > >> > and it is not part of the proposal by John Panzer originally..
>> > > > >> Ok, so you're saying service docs don't work for dynamic web >> > > > services, >> > > > >> only simple static publishing? I think they're specified rather >> > > > >> loosely and I haven't seen many non-trivial examples that would >> prove >> > > > >> what you're saying. In the absence of a specific description >> format >> > > > >> like OpenSearch, what about a WADL file?
>> > > > > we need dynamic discovery of resources (workspaces, collections), >> in >> > > > the >> > > > > absence of a "reliable" service document. >> > > > > By that I mean, a mechanism to discover the URLs for resources - >> not >> > > > > templates, but complete and accurate URLs. >> > > > > Don't know of any such mechanism available right now. No agreement >> on >> > > > WADL >> > > > > in the community yet.
>> > > > >> Sorry this is getting a little off topic from the proposed URI >> > > > template >> > > > >> RPC.
>> > > > >> davep
>> > > > >> > > Right now I'm assuming the three workspaces: people, >> activities >> > > > and >> > > > >> > > app data, but if the app data store is not the right place to >> > > > store >> > > > >> > > this info, maybe we could add another workspace with app >> urls. >> > > > >> > > Navigating these docs can be a little heavy weight so maybe >> we >> > > > could >> > > > >> > > expose the methods we use to generate it for quicker >> > > > json-rpc-like >> > > > >> > > access.
>> > > > >> > > davep
>> > > > >> > > > - How long should the template live? Is it permanent, or >> can >> > > > the >> > > > >> > container >> > > > >> > > > specify an expiration (again by returning an object)?
>> > > > >> > > > Or we can do something else entirely, but if people have >> strong >> > > > >> > objections, >> > > > >> > > > let's get another proposal on the table before the 18th.
On Fri, Apr 25, 2008 at 9:54 AM, Louis Ryan <lr...@google.com> wrote: > Im also a tentative +1 here but I think some details need to be worked out > before committing
> Is the existing mechanism of extracting parentURL from the URL params using > the gadgets.util fine for app developers to access the 'path' variable > information?
That's an implementation specific detail, so by definition it can't be "fine" unless we standardize it (and that's just a different class of badness :)).
Which id's are we talking about here. This may be a problem unique to Orkut
> but we have used a different id space for opensocial than the one we use for > our URLs, open social owner id != page owner id. I'm loath to propose > modifying the spec to include a NAVIGATION_ID to resolve this issue but...
> 'params' are currently exposed as JSON objects in gadgets js, are we > proposing changing this to query encoded and have apps accommodate the > associated change in structure this implies?
> What rules do we expect containers to enforce about the naming conventions > of params. Most containers are likely to have a diverse though small set of > always reserved params. Does the spec need to say something about this?
This seems like asking for trouble. There should be standard ways to get access to params (such as we see with view parameters), but standardizing how they are passed will make things very difficult for containers, especially those based on limited application frameworks that refuse to accept doing things any way other than the one that they like.
>> This returns a string containing "${}" variables. The four supported >> variables are: >> - name: the name or id of the application >> - owner: the id of the owner of the page >> - path: an application-defined path string >> - params: application-defined parameters, query-encoded.
>> I -think- we have +1s from kevin, graham, brandon, and fernman. >> If this is right and we get one more person to +1 then it is good to go.
>> - Cassie
>> On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com> wrote:
>>> +1 from LinkedIn. Especially when it comes to embedded links to canvas >>> pages in activity feeds. We had discussed making our own ${canvas_url} >>> token and do replacement on our servers, but we know developers are >>> going to want to generate these URLs on their own servers. Basically >>> points 2 & 6 that Nat made in the original post.
>>> -Brandon
>>> On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote: >>> > I agree with Graham -- being able to pre-generate urls is very >>> important, >>> > especially when the data is ultimately fetched over HTTP and can't take >>> > advantage of templating mechanisms and the like. My chief concern is >>> > ensuring that the url generation scheme is sound.
>>> > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> >>> wrote: >>> > > The main reason I had proposed the container URL template approach >>> was so >>> > > that developers could quickly and easily generate URLs on their own >>> servers >>> > > without having to make either JS or RESTful API calls (except maybe >>> once the >>> > > first time).
>>> > > So I like the idea of having a JS function that actually generates >>> the >>> > > URL, but I don't think it's sufficient if we want server-side URLs to >>> be >>> > > easy to create. Cassie -- do you have thoughts or suggestions about >>> the >>> > > server-side URL issue?
>>> > > --g
>>> > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
>>> > > > Okay - going back to the js apis for a moment. Graham suggested a >>> > > > container url template approach. I would like to propose an >>> additional >>> > > > solution:
>>> > > > /** >>> > > > * Returns a url for navigating to the current app on the given >>> > > > surface. Will include the path and parameters in the url. Similar >>> to >>> > > > requestNavigateTo. >>> > > > * >>> > > > * @param {gadgets.views.View} view The view to navigate to >>> > > > * @param {String} path The path to navigate to >>> > > > * @param {Map.<String, String>} opt_params Parameters to >>> pass to >>> > > > the >>> > > > * gadget after it has been navigated to on the surface >>> > > > * >>> > > > * @return {String} a url that can be used by the gadget >>> > > > * @member opensocial >>> > > > */ >>> > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
>>> > > > So, for 0.8 would we rather:
>>> > > > 1. Add a method to fetch a url template from the container. This >>> would >>> > > > be what Graham proposed (except it might fit better on the >>> > > > gadgets.views object instead of opensocial) or >>> > > > 2. Add a method to get a url for a given surface, path and set of >>> > > > params. (The method right above)
>>> > > > Please vote or suggest other proposals.
>>> > > > Thanks!
>>> > > > - Cassie
>>> > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <vasun...@gmail.com
>>> > > > wrote:
>>> > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer < >>> > > > david.prim...@gmail.com> >>> > > > > wrote:
>>> > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori < >>> vasun...@gmail.com> >>> > > > >> wrote: >>> > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer >>> > > > >> > <david.prim...@gmail.com> >>> > > > >> > wrote: >>> > > > >> > > I don't know why OpenSocial chose ${} but I don't see a >>> reason >>> > > > for a >>> > > > >> > > divergence from Joe's draft spec
>>> > > > >> > > I also want to add that in addition, the API server will >>> provide >>> > > > a >>> > > > >> > > service document to allow clients to discover the various >>> > > > endpoints >>> > > > >> > > available.
>>> > > > >> > It is really not possible to statically enumerate the >>> collections >>> > > > on, >>> > > > >> > for >>> > > > >> > example Person or Activity because many of the collections are >>> > > > defined >>> > > > >> > based >>> > > > >> > on the data available. >>> > > > >> > For example, friends of FOO collection is defined when FOO is >>> a >>> > > > valid >>> > > > >> > Person. If the person doesn't exist, then a service document >>> cannot >>> > > > >> > include >>> > > > >> > this collection - but it doesn't mean the collection won't >>> exist in >>> > > > the >>> > > > >> > future. >>> > > > >> > Worse yet, the above collection may exist at the time of >>> service >>> > > > >> > document >>> > > > >> > retrieval but may not exist after sometime, if FOO is no >>> longer >>> > > > valid.
>>> > > > >> > so, implementing service document retrieval is not really that >>> > > > useful. >>> > > > >> > and it is not part of the proposal by John Panzer >>> originally..
>>> > > > >> Ok, so you're saying service docs don't work for dynamic web >>> > > > services, >>> > > > >> only simple static publishing? I think they're specified rather >>> > > > >> loosely and I haven't seen many non-trivial examples that would >>> prove >>> > > > >> what you're saying. In the absence of a specific description >>> format >>> > > > >> like OpenSearch, what about a WADL file?
>>> > > > > we need dynamic discovery of resources (workspaces, collections), >>> in >>> > > > the >>> > > > > absence of a "reliable" service document. >>> > > > > By that I mean, a mechanism to discover the URLs for resources - >>> not >>> > > > > templates, but complete and accurate URLs. >>> > > > > Don't know of any such mechanism available right now. No >>> agreement on >>> > > > WADL >>> > > > > in the community yet.
>>> > > > >> Sorry this is getting a little off topic from the proposed URI >>> > > > template >>> > > > >> RPC.
>>> > > > >> davep
>>> > > > >> > > Right now I'm assuming the three workspaces: people, >>> activities >>> > > > and >>> > > > >> > > app data, but if the app data store is not the right place >>> to >>> > > > store >>> > > > >> > > this info, maybe we could add another workspace with app >>> urls. >>> > > > >> > > Navigating these docs can be a little heavy weight so maybe >>> we >>> > > > could >>> > > > >> > > expose the methods we use to generate it for quicker >>> > > > json-rpc-like >>> > > > >> > > access.
>>> > > > >> > > davep
>>> > > > >> > > > - How long should the template live? Is it permanent, or >>> can >>> > > > the >>> > > > >> > container >>> > > > >> > > > specify an expiration (again by returning an object)?
>>> > > > >> > > > Or we can do something else entirely, but if people have >>> strong >>> > > > >> > objections, >>> > > > >> > > > let's get another proposal on the table before the 18th.
On Fri, Apr 25, 2008 at 10:04 AM, Kevin Brown <e...@google.com> wrote: > On Fri, Apr 25, 2008 at 9:54 AM, Louis Ryan <lr...@google.com> wrote:
>> Im also a tentative +1 here but I think some details need to be worked out >> before committing
>> Is the existing mechanism of extracting parentURL from the URL params >> using the gadgets.util fine for app developers to access the 'path' variable >> information?
> That's an implementation specific detail, so by definition it can't be > "fine" unless we standardize it (and that's just a different class of > badness :)).
So do we want to standardize on parentURL as the mechanism and require the gadget to figure out what to do container by container? This isnt particularly friendly but is that status quo. Another alternative is to use syndicator/container rules to expose patterns for parentURLs in the JS and provide gadgets JS utilities to extract their components
> Which id's are we talking about here. This may be a problem unique to Orkut >> but we have used a different id space for opensocial than the one we use for >> our URLs, open social owner id != page owner id. I'm loath to propose >> modifying the spec to include a NAVIGATION_ID to resolve this issue but...
>> 'params' are currently exposed as JSON objects in gadgets js, are we >> proposing changing this to query encoded and have apps accommodate the >> associated change in structure this implies?
>> What rules do we expect containers to enforce about the naming conventions >> of params. Most containers are likely to have a diverse though small set of >> always reserved params. Does the spec need to say something about this?
> This seems like asking for trouble. There should be standard ways to get > access to params (such as we see with view parameters), but standardizing > how they are passed will make things very difficult for containers, > especially those based on limited application frameworks that refuse to > accept doing things any way other than the one that they like.
Im actually proposing giving containers more control not less. ${params} doesnt provide enough information to gadget developers about what to generate
>>> This returns a string containing "${}" variables. The four supported >>> variables are: >>> - name: the name or id of the application >>> - owner: the id of the owner of the page >>> - path: an application-defined path string >>> - params: application-defined parameters, query-encoded.
>>> I -think- we have +1s from kevin, graham, brandon, and fernman. >>> If this is right and we get one more person to +1 then it is good to go.
>>> - Cassie
>>> On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com> >>> wrote:
>>>> +1 from LinkedIn. Especially when it comes to embedded links to canvas >>>> pages in activity feeds. We had discussed making our own ${canvas_url} >>>> token and do replacement on our servers, but we know developers are >>>> going to want to generate these URLs on their own servers. Basically >>>> points 2 & 6 that Nat made in the original post.
>>>> -Brandon
>>>> On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote: >>>> > I agree with Graham -- being able to pre-generate urls is very >>>> important, >>>> > especially when the data is ultimately fetched over HTTP and can't >>>> take >>>> > advantage of templating mechanisms and the like. My chief concern is >>>> > ensuring that the url generation scheme is sound.
>>>> > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com> >>>> wrote: >>>> > > The main reason I had proposed the container URL template approach >>>> was so >>>> > > that developers could quickly and easily generate URLs on their own >>>> servers >>>> > > without having to make either JS or RESTful API calls (except maybe >>>> once the >>>> > > first time).
>>>> > > So I like the idea of having a JS function that actually generates >>>> the >>>> > > URL, but I don't think it's sufficient if we want server-side URLs >>>> to be >>>> > > easy to create. Cassie -- do you have thoughts or suggestions about >>>> the >>>> > > server-side URL issue?
>>>> > > --g
>>>> > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
>>>> > > > Okay - going back to the js apis for a moment. Graham suggested a >>>> > > > container url template approach. I would like to propose an >>>> additional >>>> > > > solution:
>>>> > > > /** >>>> > > > * Returns a url for navigating to the current app on the given >>>> > > > surface. Will include the path and parameters in the url. Similar >>>> to >>>> > > > requestNavigateTo. >>>> > > > * >>>> > > > * @param {gadgets.views.View} view The view to navigate to >>>> > > > * @param {String} path The path to navigate to >>>> > > > * @param {Map.<String, String>} opt_params Parameters to >>>> pass to >>>> > > > the >>>> > > > * gadget after it has been navigated to on the surface >>>> > > > * >>>> > > > * @return {String} a url that can be used by the gadget >>>> > > > * @member opensocial >>>> > > > */ >>>> > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
>>>> > > > So, for 0.8 would we rather:
>>>> > > > 1. Add a method to fetch a url template from the container. This >>>> would >>>> > > > be what Graham proposed (except it might fit better on the >>>> > > > gadgets.views object instead of opensocial) or >>>> > > > 2. Add a method to get a url for a given surface, path and set of >>>> > > > params. (The method right above)
>>>> > > > Please vote or suggest other proposals.
>>>> > > > Thanks!
>>>> > > > - Cassie
>>>> > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori < >>>> vasun...@gmail.com> >>>> > > > wrote:
>>>> > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer < >>>> > > > david.prim...@gmail.com> >>>> > > > > wrote:
>>>> > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori < >>>> vasun...@gmail.com> >>>> > > > >> wrote: >>>> > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer >>>> > > > >> > <david.prim...@gmail.com> >>>> > > > >> > wrote: >>>> > > > >> > > I don't know why OpenSocial chose ${} but I don't see a >>>> reason >>>> > > > for a >>>> > > > >> > > divergence from Joe's draft spec
>>>> > > > >> > > I also want to add that in addition, the API server will >>>> provide >>>> > > > a >>>> > > > >> > > service document to allow clients to discover the various >>>> > > > endpoints >>>> > > > >> > > available.
>>>> > > > >> > It is really not possible to statically enumerate the >>>> collections >>>> > > > on, >>>> > > > >> > for >>>> > > > >> > example Person or Activity because many of the collections >>>> are >>>> > > > defined >>>> > > > >> > based >>>> > > > >> > on the data available. >>>> > > > >> > For example, friends of FOO collection is defined when FOO is >>>> a >>>> > > > valid >>>> > > > >> > Person. If the person doesn't exist, then a service document >>>> cannot >>>> > > > >> > include >>>> > > > >> > this collection - but it doesn't mean the collection won't >>>> exist in >>>> > > > the >>>> > > > >> > future. >>>> > > > >> > Worse yet, the above collection may exist at the time of >>>> service >>>> > > > >> > document >>>> > > > >> > retrieval but may not exist after sometime, if FOO is no >>>> longer >>>> > > > valid.
>>>> > > > >> > so, implementing service document retrieval is not really >>>> that >>>> > > > useful. >>>> > > > >> > and it is not part of the proposal by John Panzer >>>> originally..
>>>> > > > >> Ok, so you're saying service docs don't work for dynamic web >>>> > > > services, >>>> > > > >> only simple static publishing? I think they're specified rather >>>> > > > >> loosely and I haven't seen many non-trivial examples that would >>>> prove >>>> > > > >> what you're saying. In the absence of a specific description >>>> format >>>> > > > >> like OpenSearch, what about a WADL file?
>>>> > > > > we need dynamic discovery of resources (workspaces, >>>> collections), in >>>> > > > the >>>> > > > > absence of a "reliable" service document. >>>> > > > > By that I mean, a mechanism to discover the URLs for resources - >>>> not >>>> > > > > templates, but complete and accurate URLs. >>>> > > > > Don't know of any such mechanism available right now. No >>>> agreement on >>>> > > > WADL >>>> > > > > in the community yet.
>>>> > > > >> Sorry this is getting a little off topic from the proposed URI >>>> > > > template >>>> > > > >> RPC.
>>>> > > > >> davep
>>>> > > > >> > > Right now I'm assuming the three workspaces: people, >>>> activities >>>> > > > and >>>> > > > >> > > app data, but if the app data store is not the right place >>>> to >>>> > > > store >>>> > > > >> > > this info, maybe we could add another workspace with app >>>> urls. >>>> > > > >> > > Navigating these docs can be a little heavy weight so maybe >>>> we >>>> > > > could >>>> > > > >> > > expose
Great ideas, but this is crossing the path with the templating spec. I
would suggest to get these use cases addressed in the template
specification. (that exceeds just acitivity templates)
On Apr 25, 12:22 pm, "Louis Ryan" <lr...@google.com> wrote:
> On Fri, Apr 25, 2008 at 10:04 AM, Kevin Brown <e...@google.com> wrote:
> > On Fri, Apr 25, 2008 at 9:54 AM, Louis Ryan <lr...@google.com> wrote:
> >> Im also a tentative +1 here but I think some details need to be worked out
> >> before committing
> >> Is the existing mechanism of extracting parentURL from the URL params
> >> using the gadgets.util fine for app developers to access the 'path' variable
> >> information?
> > That's an implementation specific detail, so by definition it can't be
> > "fine" unless we standardize it (and that's just a different class of
> > badness :)).
> So do we want to standardize on parentURL as the mechanism and require the
> gadget to figure out what to do container by container? This isnt
> particularly friendly but is that status quo. Another alternative is to use
> syndicator/container rules to expose patterns for parentURLs in the JS and
> provide gadgets JS utilities to extract their components
> > Which id's are we talking about here. This may be a problem unique to Orkut
> >> but we have used a different id space for opensocial than the one we use for
> >> our URLs, open social owner id != page owner id. I'm loath to propose
> >> modifying the spec to include a NAVIGATION_ID to resolve this issue but...
> >> 'params' are currently exposed as JSON objects in gadgets js, are we
> >> proposing changing this to query encoded and have apps accommodate the
> >> associated change in structure this implies?
> >> What rules do we expect containers to enforce about the naming conventions
> >> of params. Most containers are likely to have a diverse though small set of
> >> always reserved params. Does the spec need to say something about this?
> > This seems like asking for trouble. There should be standard ways to get
> > access to params (such as we see with view parameters), but standardizing
> > how they are passed will make things very difficult for containers,
> > especially those based on limited application frameworks that refuse to
> > accept doing things any way other than the one that they like.
> Im actually proposing giving containers more control not less. ${params}
> doesnt provide enough information to gadget developers about what to
> generate
> >> On Mon, Apr 21, 2008 at 4:13 AM, Cassie <d...@google.com> wrote:
> >>> Okay, container templates it is. So, for a proposal like this:
> >>> (I included an owner param)
> >>> This returns a string containing "${}" variables. The four supported
> >>> variables are:
> >>> - name: the name or id of the application
> >>> - owner: the id of the owner of the page
> >>> - path: an application-defined path string
> >>> - params: application-defined parameters, query-encoded.
> >>> I -think- we have +1s from kevin, graham, brandon, and fernman.
> >>> If this is right and we get one more person to +1 then it is good to go.
> >>> - Cassie
> >>> On Fri, Apr 18, 2008 at 3:52 AM, Brandon Duncan <dud...@gmail.com>
> >>> wrote:
> >>>> +1 from LinkedIn. Especially when it comes to embedded links to canvas
> >>>> pages in activity feeds. We had discussed making our own ${canvas_url}
> >>>> token and do replacement on our servers, but we know developers are
> >>>> going to want to generate these URLs on their own servers. Basically
> >>>> points 2 & 6 that Nat made in the original post.
> >>>> -Brandon
> >>>> On Apr 14, 12:16 pm, "Kevin Brown" <e...@google.com> wrote:
> >>>> > I agree with Graham -- being able to pre-generate urls is very
> >>>> important,
> >>>> > especially when the data is ultimately fetched over HTTP and can't
> >>>> take
> >>>> > advantage of templating mechanisms and the like. My chief concern is
> >>>> > ensuring that the url generation scheme is sound.
> >>>> > On Mon, Apr 14, 2008 at 11:50 AM, Graham Spencer <g...@google.com>
> >>>> wrote:
> >>>> > > The main reason I had proposed the container URL template approach
> >>>> was so
> >>>> > > that developers could quickly and easily generate URLs on their own
> >>>> servers
> >>>> > > without having to make either JS or RESTful API calls (except maybe
> >>>> once the
> >>>> > > first time).
> >>>> > > So I like the idea of having a JS function that actually generates
> >>>> the
> >>>> > > URL, but I don't think it's sufficient if we want server-side URLs
> >>>> to be
> >>>> > > easy to create. Cassie -- do you have thoughts or suggestions about
> >>>> the
> >>>> > > server-side URL issue?
> >>>> > > --g
> >>>> > > On Mon, Apr 14, 2008 at 5:53 AM, Cassie <d...@google.com> wrote:
> >>>> > > > Okay - going back to the js apis for a moment. Graham suggested a
> >>>> > > > container url template approach. I would like to propose an
> >>>> additional
> >>>> > > > solution:
> >>>> > > > /**
> >>>> > > > * Returns a url for navigating to the current app on the given
> >>>> > > > surface. Will include the path and parameters in the url. Similar
> >>>> to
> >>>> > > > requestNavigateTo.
> >>>> > > > *
> >>>> > > > * @param {gadgets.views.View} view The view to navigate to
> >>>> > > > * @param {String} path The path to navigate to
> >>>> > > > * @param {Map.<String, String>} opt_params Parameters to
> >>>> pass to
> >>>> > > > the
> >>>> > > > * gadget after it has been navigated to on the surface
> >>>> > > > *
> >>>> > > > * @return {String} a url that can be used by the gadget
> >>>> > > > * @member opensocial
> >>>> > > > */
> >>>> > > > gadgets.views.getUrlFor = function(surface, path, opt_params) {};
> >>>> > > > So, for 0.8 would we rather:
> >>>> > > > 1. Add a method to fetch a url template from the container. This
> >>>> would
> >>>> > > > be what Graham proposed (except it might fit better on the
> >>>> > > > gadgets.views object instead of opensocial) or
> >>>> > > > 2. Add a method to get a url for a given surface, path and set of
> >>>> > > > params. (The method right above)
> >>>> > > > Please vote or suggest other proposals.
> >>>> > > > Thanks!
> >>>> > > > - Cassie
> >>>> > > > On Thu, Apr 10, 2008 at 9:36 PM, Vasudeva Nori <
> >>>> vasun...@gmail.com>
> >>>> > > > wrote:
> >>>> > > > > On Thu, Apr 10, 2008 at 12:24 PM, David Primmer <
> >>>> > > > david.prim...@gmail.com>
> >>>> > > > > wrote:
> >>>> > > > >> On Thu, Apr 10, 2008 at 12:01 PM, Vasudeva Nori <
> >>>> vasun...@gmail.com>
> >>>> > > > >> wrote:
> >>>> > > > >> > On Thu, Apr 10, 2008 at 11:25 AM, David Primmer
> >>>> > > > >> > <david.prim...@gmail.com>
> >>>> > > > >> > wrote:
> >>>> > > > >> > > I don't know why OpenSocial chose ${} but I don't see a
> >>>> reason
> >>>> > > > for a
> >>>> > > > >> > > divergence from Joe's draft spec
> >>>> > > > >> > > I also want to add that in addition, the API server will
> >>>> provide
> >>>> > > > a
> >>>> > > > >> > > service document to allow clients to discover the various
> >>>> > > > endpoints
> >>>> > > > >> > > available.
> >>>> > > > >> > It is really not possible to statically enumerate the
> >>>> collections
> >>>> > > > on,
> >>>> > > > >> > for
> >>>> > > > >> > example Person or Activity because many of the collections
> >>>> are
> >>>> > > > defined
> >>>> > > > >> > based
> >>>> > > > >> > on the data available.
> >>>> > > > >> > For example, friends of FOO collection is defined when FOO is
> >>>> a
> >>>> > > > valid
> >>>> > > > >> > Person. If the person doesn't exist, then a service document
> >>>> cannot
> >>>> > > > >> > include
> >>>> > > > >> > this collection - but it doesn't mean the collection won't
> >>>> exist in
> >>>> > > > the
> >>>> > > > >> > future.
> >>>> > > > >> > Worse yet, the above collection may exist at the time of
> >>>> service
> >>>> > > > >> > document
> >>>> > > > >> > retrieval but may not exist after sometime, if FOO is no
> >>>> longer
> >>>> > > > valid.
> >>>> > > > >> > so, implementing service document retrieval is not really
> >>>> that
> >>>> > > > useful.
> >>>> > > > >> > and it is not part of the proposal by John Panzer
> >>>> originally..
> >>>> > > > >> Ok, so you're saying service docs don't work for dynamic web
> >>>> > > > services,
> >>>> > > > >> only simple static publishing? I think they're specified rather
> >>>> > > > >> loosely and I haven't seen many non-trivial examples that would
> >>>> prove
> >>>> > > > >> what you're saying. In the absence of a specific description
> >>>> format
> >>>> > > > >> like OpenSearch, what about a WADL file?
> >>>> > > > > we need dynamic discovery of resources (workspaces,
> >>>> collections), in
> >>>> > > > the
> >>>> > > > > absence of a "reliable" service document.
> >>>> > > > > By that I mean, a mechanism to discover the URLs for resources -
> >>>> not
> >>>> > > > > templates, but complete and accurate URLs.
> >>>> > > > > Don't know of any such
|
