New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spiderable documents (content in HTTP response) #7

Open
cben opened this Issue Sep 3, 2013 · 8 comments

Comments

Projects
None yet
1 participant
@cben
Owner

cben commented Sep 3, 2013

Search engines, or Javascript-less frontends (links, curl) etc. should be getting a at least a plain-text version of the document content (in a text area). Bonus points for:

  • rendering links as links.
  • full server-side CodeMirror styling.

Either way needs node.js on the server.

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Oct 14, 2013

Owner

Also, would be nice to provide a simple REST interface for getting the markdown content instead of rendered html.

Owner

cben commented Oct 14, 2013

Also, would be nice to provide a simple REST interface for getting the markdown content instead of rendered html.

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Feb 16, 2014

Owner
  • Fallback editing flow for users without Javascript:
    • Minimum: append a comment.
    • Ideally: Wikipedia-like [Edit section] links.
Owner

cben commented Feb 16, 2014

  • Fallback editing flow for users without Javascript:
    • Minimum: append a comment.
    • Ideally: Wikipedia-like [Edit section] links.
@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Jul 26, 2014

Owner

Try http://www.brombone.com/ ?
Hmm, $39/mo for 200 pages is too small IIUC (mathdown has ~300 docs now),
$129/mo for 50,000 Pages is enough.
But that's a bit expensive for me for a free site. Plus I don't want another proprietary part.
And with headless now supported by firepad, it should be very easy to implement myself.

Owner

cben commented Jul 26, 2014

Try http://www.brombone.com/ ?
Hmm, $39/mo for 200 pages is too small IIUC (mathdown has ~300 docs now),
$129/mo for 50,000 Pages is enough.
But that's a bit expensive for me for a free site. Plus I don't want another proprietary part.
And with headless now supported by firepad, it should be very easy to implement myself.

@cben cben referenced this issue Dec 3, 2014

Open

Accessibility #60

0 of 7 tasks complete
@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Dec 3, 2014

Owner

Optimize critical time-to-visible-text:
(some of these could be done without server side, but having a server simplifies some tradeoffs)

  • Make Firepad and CodeMirror JS async, start with read-only and/or unstyled text ASAP
    (Issue: how to know Firepad and CodeMirror finished loaded? Might need RequireJS or similar to get a callback.)
    • Initial text can come on client from Firepad snapshot via firebase REST api (because it's dead simple),
      or from server-side (which could use snapshot if it's fresh [enough] but can probably do full OT composition because Cloud Networks are Fast).
      Coming from server has the benefit that it can be styled without CM loading latency, and we need server-styled content anyway for the original goal that docs to be search-engine friendly (with headings structure, real links etc).
    • It would be great if Firepad snapshots were eventually consistent so they could serve as server-side cache.
    • I see no easy way to bootstrap client's firepad state from server's reconstruction, so the work will have to be duplicated.
  • Conversely, make sure client can start loading JS, connecting to Firebase and even editing before server response is complete.

Good reading on browser critical path: http://www.sitepoint.com/optimizing-critical-rendering-path/

Owner

cben commented Dec 3, 2014

Optimize critical time-to-visible-text:
(some of these could be done without server side, but having a server simplifies some tradeoffs)

  • Make Firepad and CodeMirror JS async, start with read-only and/or unstyled text ASAP
    (Issue: how to know Firepad and CodeMirror finished loaded? Might need RequireJS or similar to get a callback.)
    • Initial text can come on client from Firepad snapshot via firebase REST api (because it's dead simple),
      or from server-side (which could use snapshot if it's fresh [enough] but can probably do full OT composition because Cloud Networks are Fast).
      Coming from server has the benefit that it can be styled without CM loading latency, and we need server-styled content anyway for the original goal that docs to be search-engine friendly (with headings structure, real links etc).
    • It would be great if Firepad snapshots were eventually consistent so they could serve as server-side cache.
    • I see no easy way to bootstrap client's firepad state from server's reconstruction, so the work will have to be duplicated.
  • Conversely, make sure client can start loading JS, connecting to Firebase and even editing before server response is complete.

Good reading on browser critical path: http://www.sitepoint.com/optimizing-critical-rendering-path/

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Dec 13, 2014

Owner
  • Test whether text can be read via Pocket, Instapaper, Android chrome's reader mode etc.
Owner

cben commented Dec 13, 2014

  • Test whether text can be read via Pocket, Instapaper, Android chrome's reader mode etc.

@cben cben referenced this issue Jan 25, 2015

Closed

Security: HTTPS #6

3 of 3 tasks complete

@cben cben referenced this issue Feb 10, 2015

Open

First load speed #68

0 of 5 tasks complete

@cben cben referenced this issue Apr 19, 2015

Open

Read and write offline #51

0 of 4 tasks complete

@cben cben changed the title from Spiderable documents to Spiderable documents (content in HTTP response) May 21, 2015

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Jun 4, 2015

Owner

If I'm considering server-side math rendering, SVG is dramatically smaller than HTML-CSS:
cben/CodeMirror-MathJax#35 (comment)

But since the main goal here is sematically appropriate HTTP response, I should at most send the MathML.
And probably none of that, since server-side math typesetting would slow down the critical path, and reduce server scalability.

Owner

cben commented Jun 4, 2015

If I'm considering server-side math rendering, SVG is dramatically smaller than HTML-CSS:
cben/CodeMirror-MathJax#35 (comment)

But since the main goal here is sematically appropriate HTTP response, I should at most send the MathML.
And probably none of that, since server-side math typesetting would slow down the critical path, and reduce server scalability.

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Jun 4, 2015

Owner

In other news, as discovered on #56, it's presently impossible to create Firepad.Headless instances without leaking memory and CPU. Need to discuss upstream.

Owner

cben commented Jun 4, 2015

In other news, as discovered on #56, it's presently impossible to create Firepad.Headless instances without leaking memory and CPU. Need to discuss upstream.

@cben cben added this to the "beta" milestone Aug 3, 2015

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Aug 29, 2015

Owner

Idea inspired by TiddlyWiki and https://github.com/jldec/pub-server:
Ideally the generated HTML should include doc id and full firepad state — current text, revision number & outstanding local changes — such that it can be Save As...d and later opened offline, edited some more, Saved and opened again — and eventually seamlessly sync when we come online.

EDIT: this requires much deeper changes than generated HTML — firepad would need to constantly keep all its state inside the DOM.

Of course OT's automatic merge is not very safe for major disconnected editing.
But it feels like a great yardstick to measure "semantic completeness" of the served HTML.
Plus lays some groundwork for offline use (#51).
Plus would speed up client side firepad init compared to repeating the server's work of loading from firebase. (OTOH, client loading from scratch feels much more bug-proof.)

Owner

cben commented Aug 29, 2015

Idea inspired by TiddlyWiki and https://github.com/jldec/pub-server:
Ideally the generated HTML should include doc id and full firepad state — current text, revision number & outstanding local changes — such that it can be Save As...d and later opened offline, edited some more, Saved and opened again — and eventually seamlessly sync when we come online.

EDIT: this requires much deeper changes than generated HTML — firepad would need to constantly keep all its state inside the DOM.

Of course OT's automatic merge is not very safe for major disconnected editing.
But it feels like a great yardstick to measure "semantic completeness" of the served HTML.
Plus lays some groundwork for offline use (#51).
Plus would speed up client side firepad init compared to repeating the server's work of loading from firebase. (OTOH, client loading from scratch feels much more bug-proof.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment