[annotator-dev] Annotator and Meteor

Tue Sep 9 18:24:58 UTC 2014

Actually, I just had another idea. The actual reason we want access to
xpath-range is so that we can consume the ranges that are stored in
annotation objects (SerializedRanges, if I understand correctly) and
compare two of them to determine their relative position in the annotated
document. We would like to display a list of annotations in the order that
they appear in the document. Perhaps it would make sense to simply add such
a comparison function to annotator? Or maybe there's a better way of
accomplishing the desired sorting that I'm unaware of?

Thanks.

Ari

On Tue, Sep 9, 2014 at 1:24 PM, Ari Entlich <atrigent at gmail.com> wrote:

> On Sat, Sep 6, 2014 at 9:58 PM, Randall Leeds <tilgovi at hypothes.is> wrote:
>
>> I think whatever you do is a stopgap for now.
>>
>> If it helps we can push (I think we already have?) a dev tag to npm.
>>
>> Build a separate repo for the meteor package that depends on annotator
>> and you should hopefully get the built files if we're doing our part to
>> upload the build.
>>
> On Sun, Sep 7, 2014 at 12:34 AM, Randall Leeds <tilgovi at hypothes.is>
> wrote:
>
>> npm dependency for the meteor build. Then npm has the built sources.
>> Meteor package doesn't know or care about browserify.
>>
>> If any downstream consumer has to care that we use browserify we're doing
>> it wrong.
>>
>> The output is JavaScript.
>>
> Ah ok, I do see that the annotator stuff uploaded to npm is just the
> generated js files. That's probably good enough for most use cases, but
> we've been thinking of customizing the browserify build to give us access
> to the bundle's internal copy of xpath-range. To do this, I believe we
> would need to care about the use of browserify. We could potentially create
> meteor packages for both annotator and xpath-range and use both of them,
> but it looks to me like the xpath-range in npm is NOT fully preprocessed -
> the coffeescript step has been run, but the browserify step has not. In
> general though, I do think it makes sense for us to just use the copy
> inside the annotator bundle, since it's already there.
>
> Ari
>
>
>> On Sep 6, 2014 11:47 AM, "Ari Entlich" <atrigent at gmail.com> wrote:
>>
>>> Hey all. Sorry for not jumping in sooner.
>>>
>>> Mitar, I did discover your annotator package in peerlibrary while
>>> looking through your work. However, Andrew and Bryan are correct that
>>> you're using an older version than we are and that your approach
>>> unfortunately will not work for us. I don't believe it is possible to just
>>> "ignore browserify", because the most recent annotator code is making
>>> extensive use of the CommonJS-like module system that browserify provides.
>>> As far as I know, meteor would not serve as an adequate replacement for
>>> browserify in this respect.
>>>
>>> Essentially what needs to happen is that we need to have meteor call
>>> browserify during its build process. I've found
>>> Plugin.registerSourceHandler, which allows you to make build plugins that
>>> say "I can handle files with filenames matching some pattern". However,
>>> this seems to be aimed primarily at registering generic handlers for file
>>> types - coffescript, less, sass, etc files. What we need is a way to
>>> specify how to build a specific package and to add the build artifacts from
>>> that build process to the meteor app. I'm currently investigating whether
>>> it would be possible to do it in the package definition section of the
>>> package.js file (http://docs.meteor.com/#pack_onUse).
>>>
>>> If the above winds up working, we can easily tell browserify to expose
>>> the annotator bundle's copy of xpath-range. I'd rather not make changes to
>>> annotator itself in order to get this working.
>>>
>>> A possible alternative to using git submodules is to simply declare
>>> annotator as an npm dependency of the meteor package. If that winds up
>>> working, I think it would be the preferable approach.
>>>
>>> Ari
>>>
>>>
>>> On Fri, Sep 5, 2014 at 9:13 PM, Mitar <mmitar at gmail.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> You can package xpath-range as additional package as well, if you want.
>>>>
>>>> If you want to add xpath-range, you can always just add it inside the
>>>> Meteor package for Annotator as a field of top-level object. So you
>>>> create one more file which you add at the end of all files from
>>>> Annotator and do something like:
>>>>
>>>> Annotator['xpath-range'] = xpath-range;
>>>>
>>>> Please start a repository and then we can look into the real code you
>>>> have. Now it is a bit too abstract which issues you and how to advise
>>>> you.
>>>>
>>>>
>>>> Mitar
>>>>
>>>> On Fri, Sep 5, 2014 at 12:24 PM, Bryan <btbonval at gmail.com> wrote:
>>>> > Thanks Mitar, a git submodule might be a good approach for us.
>>>> >
>>>> > One of our issues is with respect to the encoding of Annotator xpath
>>>> > offsets. We would rather not duplicate this code, but we do need
>>>> access to
>>>> > xpath-range. As Annotator works now, it appears to include
>>>> xpath-range via
>>>> > browserify, but browserify does not expose xpath-range to the greater
>>>> Meteor
>>>> > application.
>>>> > -Bryan
>>>> >
>>>> >
>>>> > On Fri, Sep 5, 2014 at 3:13 PM, Mitar <mmitar at gmail.com> wrote:
>>>> >>
>>>> >> Hi!
>>>> >>
>>>> >> Yes, we are still using the old version, but I am not sure it
>>>> matters.
>>>> >> You can package it in the same way, I believe. So you add Annotator
>>>> as
>>>> >> a git submodule, you ignore browserify, and just add all CoffeeScript
>>>> >> files to the package. Meteor will then convert them into JavaScript
>>>> >> files and package them into one namespace automatically. Sometimes
>>>> you
>>>> >> have just to add one more file which exposes globally the symbols you
>>>> >> want to have globally.
>>>> >>
>>>> >> I don't have time to do it myself now, but you can start with a
>>>> GitHub
>>>> >> repository for it now and let's see where you get stuck.
>>>> >>
>>>> >>
>>>> >> Mitar
>>>> >>
>>>> >> On Fri, Sep 5, 2014 at 5:16 AM, Andrew - FinalsClub
>>>> >> <andrew at finalsclub.org> wrote:
>>>> >> > Thanks Mitar,
>>>> >> >
>>>> >> > I notice you are using an older version of Annotator (before
>>>> browserify
>>>> >> > was added). Would the same thing be possible with Annotator 2.0?
>>>> We are
>>>> >> > currently a bit stumped. Ari can share more details on our efforts
>>>> if you're
>>>> >> > curious.
>>>> >> >
>>>> >> > Eventually, it would be useful to make a Meteor package so others
>>>> can
>>>> >> > easily use Annotator in their meteor projects. If you have any
>>>> suggestions,
>>>> >> > we would love guidance / help.
>>>> >> >
>>>> >> > Warmly,
>>>> >> > Andrew
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >> On Sep 5, 2014, at 3:39 AM, Mitar <mmitar at gmail.com> wrote:
>>>> >> >>
>>>> >> >> Hi!
>>>> >> >>
>>>> >> >> You can see here how we are bundling Annotator for Meteor:
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> https://github.com/peerlibrary/peerlibrary/tree/development/packages/annotator
>>>> >> >>
>>>> >> >> And here how we are using it:
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> https://github.com/peerlibrary/peerlibrary/tree/development/client/lib/annotator
>>>> >> >>
>>>> >> >>
>>>> >> >> Mitar
>>>> >> >>
>>>> >> >> On Wed, Sep 3, 2014 at 7:04 AM, Andrew - FinalsClub
>>>> >> >> <andrew at finalsclub.org> wrote:
>>>> >> >>> Hey All,
>>>> >> >>>
>>>> >> >>> Especially @Mitar. At FinalsClub, we have been working on a new
>>>> social
>>>> >> >>> reading site built using Meteor (a newfangled JavaScript
>>>> framework). Meteor
>>>> >> >>> is nice, because it offers isomorphic JavaScript - that is, the
>>>> same code to
>>>> >> >>> run on the client and server. It also provides the magic of
>>>> reactive data
>>>> >> >>> binding between clients and server.
>>>> >> >>>
>>>> >> >>> We have gotten a basic working version of Annotator with a
>>>> >> >>> meteor-specific store plugin. (I can share the code if anyone is
>>>> curious.).
>>>> >> >>> However, there are some aspects of Annotator that we are
>>>> grappling with.
>>>> >> >>>
>>>> >> >>> For instance, we were wondering how the XPath-Range plugin is
>>>> >> >>> currently being used. Also, we want to include the coffeescript
>>>> (not
>>>> >> >>> compiled JS) of Annotator in our project, but aren't sure how to
>>>> accomplish
>>>> >> >>> that using Meteor's custom package system.
>>>> >> >>>
>>>> >> >>> @Mitar, I've seen your handle on a few meteor github issues and
>>>> wonder
>>>> >> >>> if could help us. I've cc'd Bryan and Ari from our team if they
>>>> have
>>>> >> >>> anything to add.
>>>> >> >>>
>>>> >> >>> Also, if anyone else is interested in helping, just say so. We'd
>>>> be
>>>> >> >>> glad to put our work on the OpenAnnotation organization if you'd
>>>> like as
>>>> >> >>> well.
>>>> >> >>>
>>>> >> >>> Best,
>>>> >> >>> Andrew
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> http://mitar.tnode.com/
>>>> >> >> https://twitter.com/mitar_m
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> http://mitar.tnode.com/
>>>> >> https://twitter.com/mitar_m
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> http://mitar.tnode.com/
>>>> https://twitter.com/mitar_m
>>>>
>>>
>>>
>>> _______________________________________________
>>> annotator-dev mailing list
>>> annotator-dev at lists.okfn.org
>>> https://lists.okfn.org/mailman/listinfo/annotator-dev
>>> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140909/9ced3f01/attachment-0004.html>