Re: PUSH Definitions
Subject: Re: PUSH Definitions
From: Clark Robinson <robinsonchicago@gmail.com>
Date: 7/22/10, 18:03
To: Scott Mintz <scott.w.mintz@gmail.com>
CC: Barrett Brown <barriticus@gmail.com>

Re: stuff highlighted in green, for the bloggers, I guess passwords are going to be necessary.  I don't think they will be necessary for the readers, unless we have a messaging system, in which case I suppose the readers will have to have passwords, also, since they will need to have a way to associate reader widget ID codes with the owners's identity in order to know how to message their buddies. I am kind of inclined to think we should go for a good push system in the first release, and be cautious about additional functionalities.

On Thu, Jul 22, 2010 at 4:12 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:
I did put in the BLOGGER revisions and will continue to do so. Also, I will re-word the PUSH definitions to include what you describe below. (In case you want to follow my thoughts, I plan on having a separate section for MESSAGING).

With regards to messages, I too have been thinking how this could be done on a server-less network. One thought that came to mind is that based on the assumption every Project PM widget hosted a particular blog has a unique ID then another widget could be given commands to ping that ID until it received back an indicator that it's active then sends a message to that widget, which could (1) be AON (all or nothing) or (2) get stored in that widget like the posting queue.

While thinking about this and the PUSH definitions it came to my attention that some mechanism, such as the previously unique coded identifiers will absolutely be necessary to ensure that someone does not incorrectly have the ability to push someone's work. IP address came to mind but that changes for people if its dynamic, if they log in from different locations, and they can also be spoofed. Maybe Barrett's people will have a good idea on this front.


On Thu, Jul 22, 2010 at 3:16 AM, Clark Robinson <robinsonchicago@gmail.com> wrote:
Go ahead and copy this stuff into the spreadsheet as a general comment. Only thing I would add, in reference to the pink highlighted text, is that the primary push blogger has to have open the post itself (as if he/she was reading comments to it), so that the push sends the URL unique to the post itself, and not the URL of the blog's home page.  This is already in the specs but maybe needs to be repeated in this context. Perhaps the widget will need to be able to distinguish homepage URLs from post-specific URLs and error-message a blogger who attempts to push a homepage URL.

Scott, did you swap the revisions you sent me yesterday into the appropriate fields in the spreadsheet, or do you need me to do that?

Also, If you can figure out a simple internal messaging system using the widget identifier codes, I would say go ahead and describe it in the spreadsheet; it does not hurt to propose stuff, and the programmer can tell us if its feasible or not.  As I said, and speaking only for myself, my goal is to get this moving, not to resolve all requirements issues, given that I don't have the requisite knowledge or experience to do that. What I can not figure out about a messaging system is how the reader would direct the message to the right person; there could easily be a milllion widgets out there, and we surely do not want to have an index with names in it for all sorts of reasons. (Too much information to store without using a server, for one thing).


On Wed, Jul 21, 2010 at 11:51 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:

Definitions:

PUSH –> There are unlimited levels of pushes (i.e. Primary, Secondary, Tertiary, etc.). Anytime a Blogger pushes a specific posting, then subsequently that blogger’s ability to push that specific posting again will cease.

Primary - A primary push occurs when a Blogger originates a post on their website and then using the Project PM widget located on that site, accesses the widget and uses the  “PUSH” function to send links along with a coded identifier to all other Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings.

Secondary – A secondary push occurs when a Blogger receives a link in queue from a Primary push with a coded identified from another Blogger, and subsequent to reviewing the posting on the originating Blogger’s website, is able to use that site’s Project PM widget along with BOTH (1) the original coded identifier and (2) their own coded identifier to “PUSH” a link in queue to all Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings, EXCLUDING both the post originator and any Bloggers that received the post in the primary push.

Tertiary – A tertiary push occurs with a Blogger received a link in queue from a Secondary push with a coded identifiers from BOTH (1) the primary both and (2) the secondary push, and subsequent to reviewing the posting on the originating Blogger’s website, is able to use that site’s Project PM widget along with ALL coded identifiers including their own to “PUSH” a link in queue to all Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings, EXCLUDING both the post originator and any Bloggers that received the post in the primary or secondary pushes.