[tssg-tech] Re: [TSSG] 1st Cut at EventBoss Application Architecture
- From: Harry Henriques <harry_henriques@xxxxxxxxxxx>
- To: tssg-tech@xxxxxxxxxxxxx
- Date: Mon, 10 Jan 2011 07:28:59 -0800 (PST)
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
Other related posts:
