[annotator-dev] Yet Another Store Implementation (Ruby/Rails)

[King'ori J. Maina]

Thanks for the quick response!

Yes, I see. Been doing some reading and figured that part out and it’s in agreement with your explanation.

Most of the info out there on the OPTIONS verb seems to point out that it’s used to document an endpoint/API so was just wondering if there’s an Annotator specific purpose.

Will probably send an update in the next few days.

— King’ori Maina (kingori.co <http://kingori.co/>)

> On Oct 14, 2014, at 4:16 PM, Aron Carroll <aron at hypothes.is> wrote:
> 
> On 14 Oct 2014, at 16:04, King'ori J. Maina <j at kingori.co> wrote:
> 
>> I’m working on Ruby/Rails powered Annotator storage implementation for Annotator using the Core storage and search API documentation as guides. Seems to be going well so far (though I have a question for the core team at the end of this email).
> 
> Awesome!
> 
>> That said … for now, I have one question. Why does the plugin make an OPTIONS request to the store? This isn’t in the docs.
> 
> That’s a CORS (Cross Origin Resource Sharing) preflight request[1]. It’s not part of the annotator client because it’s performed by the browser when it makes a request to any url that doesn’t match the current document. I recommend reading the linked article. You can choose to handle this in the request handlers of your engine or combine it with something like rack-cors[2].
> 
> [1]: http://www.html5rocks.com/en/tutorials/cors/#toc-handling-a-not-so-simple-request
> [2]: https://github.com/cyu/rack-cors
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20141014/728f61e8/attachment-0004.html>