Requirements

##Offline Editing

###Use cases:

1. The client needs the ability to ADD, UPDATE, DELETE points, lines and polygon features while offline. [OK]
2. The client needs the ability to undo/redo a queued/pending edit. In other words, the client needs to be able to modify or delete a queued edit that is stored on the client application and controlled by the offline library.

• [Well, my view is that once you do an edit, that is done, no matter whether you are online or offline. You can always reverse an edit. For instance, you can delete a feature that you have added, but in my opinion, allowing the deletion of arbitrary edits can cause serious coherence problems. What if you do an ADD, and then and UPDATE and after you 'cancel' the ADD? What would happen to the subsequent UPDATE?]
• AG: If you ADD an item > UPDATE it > then Cancel you'd get no edit whatsoever. Only the very last edit on any single item is valid. Last edit wins.
• AG: As far as I know you cannot ADD then DELETE a feature in our queue. The ADD event will be processed, but don't we need to know the ObjectID in order to DELETE it? If that is true, we won't have that information until the ADD event is processed by the server and it issues the ObjectID in the response. The pending DELETE operation will not know that ID. I've added more information below under Req's section 3.

3. Users and application developers need information on which edits were successfully sent from the queue. [OK]
4. Users and application developers need information on edits which have not been successfully sent after a specific online time period has elapsed. [OK, for me this situation should be handled in the same way as unsuccessful edits made online]
5. Users and application developers need information when an edit failed so that the appropriate corrective action can be applied.

• [We need to determine which corrective actions are appropriate]
• AG: Agreed.

###Requirements

1. The library shall store information in the browser on all ADDs, UPDATEs and DELETEs while the application is offline. This store can also be referred to as a “queue.” [OK]
2. The library shall provide public method(s) for allowing the client to do #1 [OK]
3. The library internally needs the ability to delete an edit from its “queue” without affecting any other pending edits.

• [Why is this needed? It is much simpler to ensure data integrity if we see the queue as a real queue where elements can only be added at the end and they can only be removed from the beginning]
• AG: As mentioned above, I think there are some technical issues with maintaining the queue.
• Additional scenarios for consideration:
  • ADD item > DELETE. We won't know the ObjectId in order to insure valid deletion (unless we implement an architecture to capture that information and store it appropriately).
  • ADD item > UPDATE. I also think we need the ObjectId to perform the update. We won't get that until the ADD event has returned a valid response object. We would need a mechanism for retrieving the ObjectId and associating it with the UPDATE request?
  • DELETE > [courtesy] Undo. Following the online protocol, an item that is deleted from server can only be added again from scratch. Providing "undo" is a convenience method for the end user that eliminates the need to completely recreate an object that was, for example, accidentally deleted while offline.

4. The library internally needs the ability to modify an edit in the “queue” without affecting any other pending edits.

• [Why? It is much simpler to simply add subsequent edits to the queue. If you want to 'cancel' an ADD, then you should enqueue a DELETE. There is already support for this Undo/Redo management at the application level, using esri/dijit/editing/Editor and UndoManager classes]
• AG: I'm not 100% familiar with how the Editor works, so it's not clear to me yet that all of it's workflows will be appropriate for offline use and that should be taken into careful consideration. I think "offline" introduces some complexities, mentioned above, that it may or may not have been taken into account appropriately. If I'm wrong then cool, I'm just exercising the use cases to test if we are on the right track.

5. The library internally needs the ability to track if an ADD, UPDATE or DELETE was not successful. This is required to insure data integrity of the queue.

• [Yes, what would the appropriate action be?]
• AG: At a minimum we should provide a way to flag actions that weren't successful and assign a property that indicates what the problem might have been.

6. The library needs a mechanism for notifying the client if an edit was unsuccessful.
   • Unsuccessful events shall not be silent in order to prevent data corruption and to eliminate unintentionally mis-information to the client.
     • [Agreed. I think that the offline editing feature is not different than online editing in this regard. The app should behave in the same way and report problems to the user in the same way]
     • AG: Needs more discussion. It's not clear to me yet that offline behavior can be treated exactly the same as online for reasons mentioned above.
7. The library needs a mechanism for providing detail information to the client if an edit was unsuccessful.
   • At a minimum, the library should store information on a failed edit to include at least: objectid, datetime, attributes, geometry.
   • There shall be a distinction between an edit that failed because of a bad internet connection and an edit that failed because it was rejected by ArcGIS.
     • [Well, one is an error (ArcGIS Server rejected) and the other is a normal condition (we are offline, we keep the edit until we are online again)]
     • AG: Right, bad internet connection we keep the edit in the queue.
     • AG: However, what do we do with edits that were reject by ArcGIS Server? Delete them from the queue? Or, do we create another queue that becomes a holding pen for bad edits so that information is not lost? Send an event that some edits were rejected?
8. The library shall only delete a queued edit if the following criteria are met:
   • The pending edit was sent to server and a success property was received back. [OK]
   • The user requests to modify or delete the pending edit.
     • [I don't think this is needed and it makes preserving integrity more difficult]
     • AG: Potentially. We need to validate my queueing scenarios above (and make sure I didn't miss any others) to verify if we can take the approach you have suggested.
   • The user clears the browser cache (we have no control over this) [OK]
9. The library shall replace/modify a queued edit if the client requests an update to its properties.
   • [Disagree, the correct way to do this IMO is to enqueue another UPDATE on the same feature and replay them in order]
   • AG: It's quite possible that UPDATEs might operate under slightly different use case than ADDS or DELETE. You'll probably agree on this point. With an UPDATE we already know it's ObjectID, that's not going to change. Furthermore, it's perfectly okay that last edit wins.
10. The library shall provide a mechanism for tracking if an unsent edit is more than X hours old. [OK]