h1. Resolved - Remove the social components and maybe starting over

bq. *Changed to "resolved" on 20Aug2013.* 

I should have left these feature out to begin with, but it was hard to create the app without thinking of other people using the app on the same site.

Adding these features required a good bit of time and lines of code. I had to add one or more database tables and/or columns to existing tables. I could have spent that time honing the important parts of the app.

Either physically remove the code or disable the functions in Dispatch.pm. The latter would require commenting out the links/buttons in the template files.

Another possibility is to *start over* from scratch and copy *only* the parts that I truly want. 

*22jul2013 update:* started from scratch and copied functions that I wanted. split out modules into many more smaller modules.

Remove/Disable:

* following and unfollowing users - *kept*
* following and unfollowing tags - *kept*
* liking and unliking posts - *removed*

The ability to see who is following me was disabled a while ago. - *remains removed from code.*

It was a good exercise to add the above features, but I did not intend to have those features when I started building this app back in January/February 2013. 

*What about replying as a blog post?* Should this function be removed/disabled?  - *removed. will create a new reply mechanism*

bq. *In late July/early August 2013, added a reply mechanism that uses the microblog post format for replying. limited to 300 chars. can reply to replies, for now. can reply to blog and microblog posts.*

Replying as a blog post sounds simple enough, but this also required a fair amount of time and code to implement, and I'm not done with adding functions related to replying as a blog post.

Blog reply-related functions:

* replies given
* replies received
* hiding and unhiding the reply link on blog post page
* blocking a user from seeing the reply link
* global hide a user's blog reply links on all of a user's (my) blog posts
* enforcing the idea of only one reply per blog post
* probably other related functions were needed

Not everything above has been added yet, so now is a good time to decide if blog replies will continue.

Commenting systems and whether to allow comments have received a lot of discussions over the past year, at least. People are trying re-invent or at least re-imagine discussion mechanisms.

The reply as a blog post idea interested me. The owner of the initial blog post gets to be the admin by hiding reply links, blocking users from replying, etc.

And replying as a blog post works, of course, if the replying user creates a blog post here on this site. 

Replying or discussions should work something like the old "trackback":http://en.wikipedia.org/wiki/Trackback idea that was created about 10 years ago by the Trotts, the creator of the blogging/cms engine "Movable Type.":http://en.wikipedia.org/wiki/Movable_Type

I'm leaning toward creating a new version of the code.  *[completed 22jul2013]* This app was called Kestrel. I planned to rename it to Junco because a message queue software app called Kestrel exists.

I'll leave this code as Kestrel. I may start over new tables, templates, modules, etc. that will be called Junco, and it will focus on my original idea. *[completed 22jul2013]*

The only so-called "social" components will be allowing other users to create an account and RSS everywhere. A user can follow other users or tags or a user's tags through RSS. *[22jul2013 not quite. of course, RSS is still everywhere, but i kept following users and following tags, and i'll create new reply mechanism.]*

Discussions? Even with reply as a blog post within this app, this app is clearly less conversational. It also has a much less discovery mechanism. It's more single-user focus, which was my initial intent. But the urge to think about other people using the app distracted me.

It will take time to pull out code and start over. But it will feel good to simplify. 

If I start over, what about content here? I've used this development Kestrel code base way too much, I guess. I want to keep the content.

If I start over with new app called Junco with new database tables, I will eventually need to create a REST mechanism so that I can import my data from Kestrel into Junco, and from my Toledo Talk microblog to Junco. *Completed in late July/early August 2013.*

Darn-it. I hate losing the features. I'll keep the code stored somewhere just in case I would like to implement blog replies or following later in Junco.


h2. Update - 20Aug2013

Right now, I do not plan to open JotHut.com to others, except possibly for friends and family. It will mainly be my personal information storage place. The new reply mechanism and the following features will remain. They are at least proof-of-concept code modules. 

#junco
#resolved
#kestrel