h1. 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



h2. 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 [not needed for now]

*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

*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.

*more_text_exists*: true or false. if the total body text is greater than X-number of chars, and it requires the "more" link on the stream home page.

-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 for now.]

-tags- : ex tags: ["nature", "bird", "home"] - (not right now)

*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

*reading_time* : in minutes

?? 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




h2. 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:

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

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


h2. 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