Hi, my comments are below in RED. Harry --------------- http://www.linkedin.com/in/harryhenriques ________________________________ From: Jim Cant <cant_jim@xxxxxxxxxxx> To: tssg tech <tssg-tech@xxxxxxxxxxxxx> Sent: Mon, January 10, 2011 10:15:10 AM Subject: [tssg-tech] Re: [TSSG] 1st Cut at EventBoss Application Architecture Hi, my two cents interspersed below jim ________________________________ From: robertdionne@xxxxxxxxxxx To: tssg-tech@xxxxxxxxxxxxx Subject: [tssg-tech] Re: [TSSG] 1st Cut at EventBoss Application Architecture Date: Mon, 10 Jan 2011 00:34:31 -0500 Hi all, I just want to bounce a couple of thoughts off the architecture design (Arch Pic_1_7_#7), just to confirm that some specific functionality is provided for. 1) Has it been decided when and how the “Model”, and therefore, the “View” will be updated. Will the Model be updated only at Application (EventBOSS) startup? Not only at startup. The data model consists of different lists of events: those fetched from the eventsource (RSS), those from the datastore( dababase) and possibly those selected from a 'Find' request. I agree, but only one list of events, backing the VIEW, exist in the MODEL at any given time. Since only one of these is displayed at a time (in the current scheme). I think that there should only be one list of events in the MODEL. The View will need to be updated when changes in these occur and also whenever the user indicates he's like to see a different subset of the data model, such as toggling between saved and current events. The VIEW will be notified to update when the data in the MODEL changes. 2) Note that “Search” functionality has been semantically replaced by the term “Find”. Will the Find component have effective access to the persistent data? Depend on how it's designed. If you build Find so that it is passed a set of events to search and returns a set of matching events, then you keep 'Find' independent of the data it works on. I think that the entire event list stored in persistent data should be brought in to RAM memory in the MODEL; the Find module will work on that data; and the Find module will return the results to RAM memory in the MODEL. If you allow Find to access the data, the when you change the data in the application, you likely break Find; also, you can't use Find in other contexts. By the way, by 'persistent data' did you mean the data saved to the event store? I think that you mean the SQLlite DataStore when you talk about persistent data. Rob ________________________________ From:tssg-tech-bounce@xxxxxxxxxxxxx [mailto:tssg-tech-bounce@xxxxxxxxxxxxx] On Behalf Of Harry Henriques Sent: Friday, January 07, 2011 6:21 PM To: TSSG-tech Subject: [tssg-tech] [TSSG] 1st Cut at EventBoss Application Architecture --------------- http://www.linkedin.com/in/harryhenriques