-
Notifications
You must be signed in to change notification settings - Fork 5
/
DESIGN
25 lines (16 loc) · 2.23 KB
/
DESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Some design considerations:
Key principle: each manipulation to be done where it's easiest to do it, i.e. don't try to solve everything during the single-pass HTML parsing (many things are just easier to do as a manipulation of the clean markdown)
PBY-icky-HTML to FRBR Entities logic: one HTML file becomes one (most commonly) or more (e.g. multiple short poems in one file) manifestations, each manifestation being of one expression (the markdown expression, also created) of one work (also created, but possibly already existing with another expression [e.g. multiple translations of same foreign work], and usually linked to an original expression elsewhere [e.g. Wikisource, Project Gutenberg]).
Implementation notes for later:
* when rendering an aggregate work as one output document (especially HTML), render each part, and post-process each output to rename the footnote anchors (if any) to avoid collisions (i.e. namespace each fragment or something).
heterogeneous feed design thoughts:
1. new table for manual elements and their status (e.g. 'pinned') and target/relevance dates
2. on-the-fly (but cached!) polling of YouTube and Wordpress for latest posts
3. Facebook posts will need to be fed manually, or reproduced entirely, due to FB's new restrictions on even public data, and its resistance to scraping.
4. sources 1+2+3 are combined (interwoven, by date) with latest BYBE content (latest works published, latest [approved!] recommendations)
5. resultant "feed" calculated every two hours and saved in cache and served from there to all site visitors.
6. certain actions (publishing new works, approving a recommendation) can trigger recalculation of newsfeed. External content (e.g. YouTube) will only be picked up once every two hours.
rendering the newsfeed should be uniform -- given a desc-sorted list of NewsItems, render each according to type.
Dictionary entries design thoughts:
* it is assumed the digitized dictionary comes sorted alphabetically. Entries record a sequence number and will always be shown and navigated across in that order.
** if a dictionary is not alphabetically sorted, a sequencing of it can still be retained, but the alphabetical navigation bar won't make sense for that dictionary, and would have to be suppressed.