Tim Williams wrote:
> Nope, it's reasonable. Have you thought through what introducing some
> of these technologies means for our static build? Just curious.
[context: "these technologies" refers to AJAX stuff I have been adding
to the DOAp plugin]
Sorry Tim, I missed this question originally.
Yes, I have thought through the implications. To date there are two
contracts I have implemented, a feed reader and Exhibit.
In both cases I have only implemented as HTML contracts so there is no
possibility of including this stuff in, for example, a PDF output where
it would make no sense (at this time).
In the case of the feed reader the content only makes sense if the feed
being read is reachable, i.e. the static deployment has access to the
web. If this is not the case then there is a sensible fallback in that
the reader can display a suitable notification that the network is not
reachable.
In the case of Exhibit the source data can be statically generated by
providing a link to the JSON file being used by Exhibit, at least that
is the case in the DOAP plugin. At present, this link must be created
manually, but it would make sense to have the Exhibit contract add a
suitable link to the page automatically.
BUT...
Right now the javascript for exhibit itself is retreived from the MIT
servers, so this means that the Exhibit contract is also only useful
when the client has a network connection. This is easily resolved
though, simply have the contract provide the necessary script files.
Ross
