- From: Mitar <
>
- To:
- Subject: Re: [PeerLibrary dev] Some ideas how to contribute
- Date: Fri, 22 Aug 2014 13:27:07 -0700
Hi!
>
> - move to Meteor Blaze (we are still using old rendering engine)
>
>
Only trivial blockers in peerlibrary's own code base as far as I can
>
see, but peerlibrary/meteor and peerlibrary/meteor-file need to be
>
updated. The later is rather trivially fed upstream, the former... No
>
idea.
Changes to meteor-file are minimal, just one open pull request which was
not merged (and just used for testing, anyway):
https://github.com/EventedMind/meteor-file/pull/17
Pretty trivial pull request.
For Meteor, I think you are right. The point is, it just has to be done
and tested. I would say, that the tricky things are:
We are currently storing instance data into data context, but this is
addressed in new Meteor version, but there will be some work to port that.
We heavily use the fact that in old rendering engine "rendered" callback
was called every time template was rerendered. This is now changed and
it is called only once. I am not sure what is the new pattern to use
here, but mostly the reason why we needed "rerendered" was to-reattach
jQuery stuff Meteor was throwing out, which Meteor is not doing anymore.
So probably it is not necessary.
The common pattern with both of above things is that they were
workaround for old rendering engine. Luckily, things can now be
simplified. But this still means it is not trivial to port, you still
have to go over everything and rewrite. Remove old hacks, clean the
code, port to new modular stuff, make Session use minimal (but it still
has valid use cases! so don't remove everything).
You will have to figure how to override Meteor templates (Meteor does
not yet provide an official way to do that).
And probably PDF.js viewer can be now better integrated.
I suggest that you start working on this, if you are interested. We
could merge this after we release 0.3 (which will be soon). And then
have new stuff ready for 0.4. (Hopefully, Blaze will also make things
faster.)
I would still use meteor-router for now, and not move to iron-router.
Just to minimize the changes.
(meteor-router is the package where we really have a fork and a lot of
changes because it is not maintained upstream anymore. This will be
trickier to do. Probably I will have to sit down once and do it. But
first we have to get to Blaze.)
Would you be interested in doing this? Create in our Meteor fork branch
peerlibrary-new, create there 0.8 + our changes (don't go to 0.9!, they
completely changed packaging there and we do not need that yet). And
then create a branch in PeerLibrary, porting it to Blaze.
Mitar
>
On Thu, Aug 21, 2014 at 10:02 AM, Mitar
>
<
>
>
wrote:
>
> Hi!
>
>
>
> I know that it is hard to get the feeling what is more or less important
>
> from all the tickets and milestones, so I brainstormed few ideas what I
>
> think could be good ways to contribute to PeerLibrary development. Some
>
> things are quite tricky, though.
>
>
>
> - implement user notifications (so that if somebody replies to your
>
> annotation you get feedback) (I will probably start working on this soon)
>
> - move to Meteor Blaze (we are still using old rendering engine)
>
> - upgrade PDF.js to newest version
>
> (https://github.com/peerlibrary/meteor-pdf.js), this should be more or
>
> less straightforward, they did change API for text extraction, so we
>
> would have to adapt this on the client (where we use it for selection)
>
> and server (where we use it for full text search), they claim they also
>
> fixed that all errors are reported through promises, so our hacks of
>
> intercepting console.log could be maybe removed
>
> - I optimized a bit loading time, but we could further analyze if we can
>
> remove things, we have some dead code and libraries we are not using or
>
> have them multiple times in
>
> - check unnecessary rerenderings and optimize (maybe we should first
>
> wait for transition to new rendering engine), we have
>
> settings-debug.json available which colors everything which is
>
> rerendered so you can observe what is happening
>
> - try to use pdf2htmlEX instead of PDF.js
>
> - upgrade Scribe to new version + we opened few GitHub tickets which are
>
> waiting on our feedback + improve the way of doing links (currently it
>
> is really hard to replace content of the link without)
>
> - change how highlights are done (so that they don't have authors)
>
> - change how collections are done
>
> (https://github.com/peerlibrary/peerlibrary/issues/448)
>
> - improve how highlights are drawn
>
> (https://github.com/peerlibrary/peerlibrary/pull/550)
>
> - if PDF has existing annotations when imported, we should convert them
>
> to our annotations, and strip PDF of them when caching
>
> - allow downloading the PDF with embedded annotations (because otherwise
>
> currently it is hard to export annotations or print the publication)
>
> - normalize the PDF on the server (reorder the text layer so that it
>
> works better when selecting)
>
> - zoom, page rotation, support PDFs with various page sizes
>
> - create Docker images for PeerLibrary and dependencies
>
> - math mode in editor
>
> - we have logo, we need business cards now
>
> - when one focus a highlight or annotation we should improve how we show
>
> that and we should scroll to it
>
> - we have to create a whitepaper explaining the idea behind PeerLibrary,
>
> annotate it, and then have it as an example
>
> - we improved how text selection is done in PDF.js and this should be
>
> sent upstream (https://github.com/mozilla/pdf.js/issues/4843)
>
> - integration of ElasticSearch for full-text search
>
>
>
> If you are interested in anything of this, say and I can tell a bit more.
>
>
>
>
>
> Mitar
>
>
>
> --
>
> http://mitar.tnode.com/
>
> https://twitter.com/mitar_m
>
>
>
> Settings and unsubscription:
>
> http://lists.peerlibrary.org/lists/info/dev
>
>
>
> Public archive:
>
> http://lists.peerlibrary.org/lists/arc/dev
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
Archive powered by MHonArc 2.6.18.