Create yet another publishing tool - Jan 2015

A January 2015 project.
Simple blog or note-taking web app.
Uses:

• Nginx for the web server
• Node.js for the "client" code on the server
• API-based
  • possibly create the initial API code in Perl
  • then create the API code in Node.js
• use the Express framework for Node.js
• use Handlebars for templating
• use CouchDB for the data store
• use Redis as the caching server

This will be a simpler app than Grebe.

• account creation and the login procedure will not use a password
• use only Markdown as the formatting markup (node.js showdown)
• two types of posts: articles and notes
• notes will function like in the Grebe app with no char limits
  • if no title, then a note. with title, then article.
• the home page will look like the stream view when logged into the Junco app with notes and articles displayed
• only the first 200 to 300 chars for notes and articles will be displayed in the stream view
• little text area box displayed at the top of the stream view when logged in, which can be used for either notes or articles
• click post link for a larger textarea box that can also used for both notes and articles
• no fancy blog-like display options for articles like in Junco with the blog_username tag and like with the default view for Grebe
• simplify CSS
  • no homepage banner image
  • borrow header and nav ideas from Grebe
• ability to display articles/notes/entire stream for a user??
• it will be multi-user
• do not put the delete/undelete functions on the stream display for logged-in users
  • move delete/undelete to the article page
• will have a search function
• Do NOT include the following features:
  • related articles
  • view article source
  • hashtags auto-linked and counts stored in separate view
• login will be done only through sending a link with mailgun

Content Description

Are multiple types offered? article, draft, note. With the way Grebe works, a note is a draft, since both are not displayed on the front page. The only diffs are the draft has an official title line and the draft=yes command while a note has neither. So an article could be a "draft" by simply remaining as a post with no official title line, which is created with either the Markdown down single pound sign or the Textile h1. command.

_id : either a generated five-character alpha ID or the slug/URI title

type : post

title : works like Grebe

slug : (uri_title in my previous apps) ex: this-is-a-test - not needed if the above _id field is based upon the URI title

format : markdown, textile, or whatever

markup : the entire original text, including title line, power commands, etc.

html : the body of the post to display. the title line is not included here

plain_text_intro : like the stream page in my Junco app where the first x-number of chars is included in the display after the HTML tags have been removed.

html_intro : new field for me. if the "more." command is used, then the HTML body text of the post that precedes the more. command is stored on this field. [don't use now.]

tags: ex tags: ["nature", "bird", "home"],

post_type : article (with a title), note (no title) or reply

author : do I need an author_id?? not right now.

created_at : 2009/02/17 21:13:39

updated_at : 2009/02/17 21:13:39

?? these two for both created and modified?? maybe not now
yr_mon_day : [2015, 01, 30]
hr_min_sec : [14, 39, 22]

post_digest : is this still needed? i don't think so. use the couchdb _rev

post_status : public, deleted ( ?? private, draft, old version ??)

parent_id : for versioning and replying to posts

User Description

_id : either the username or an auto-gen char code

type : user

user_name :

password :

email :

created_date :

user_status : (o) open, (d) deleted

desc_markup :

desc_format :

user_digest :

orig_email :

session_id : IS THIS NEEDED? - default '0', -- send in cookie, maintain login - not needed if allowing user to remain logged in through multiple devices at the same time, especially since a session_id doc_type will be used. Since this is JSON, this value could be a hash, and I would not need the session_id doc_type.

It could be:

{
  "session_ids" : [
    {
      "id" : "aasdfjkioasdfjo",
      "created" : "2015-01-14 14:54:22",
      "status" : "o"
    }
    {
      "id" : "askasdfieiedfjo",
      "created" : "2015-01-13 23:12:05",
      "status" : "o"
    }
  ]
}    

login_link_status : (o) open, (p) pending, (d) deleted

Session IDs Description

_id : this will probably be the session_id which has SQL table info of: varchar(255) not null default '0', -- send in cookie, maintain login

type : session_id

user_id or user_name :

created_date :

session_status : o open, d deleted

#scaup - #blogging - #todo