hi , If i incorporate a offline database such as SQLite GoogleGears instead for database.js , can i overcome the problem of exhibit's lowered responsivness due to large datasets. Kindly help...
thanks Sabarish S David Huynh-2 wrote: > > Mark Diggory wrote: >> A few more added comments... >> >> On Feb 7, 2008, at 4:44 PM, David Huynh wrote: >> >> >>> Note that server-side Backstage uses the URL of the exhibit as well as >>> the set of data link URLs as the key to cache the triple store. This >>> is >>> so that when several users view the same exhibit, only one triple >>> store >>> is instantiated (to save space and time). There are technical >>> challenges >>> here to address the case where the data at any one of those URLs is >>> changed after the triple store is instantiated and loaded. >>> >> >> Are you using the Sesame "Context" in terms of the key you are >> referring to above? >> > No, there are several separate triple stores, each instantiated and > loaded on demand (whenever a user views an exhibit that no other users > are currently viewing). > >>> There is another technical challenge here: if the server session >>> expires, all the interactive sessions get thrown away on the server. >>> The >>> triple store might even get thrown away if no other user is looking at >>> the same exhibit. >>> >> It makes sense then to keep the store in "memory/on disk" separate >> from the users session so that it can always be available for new >> users, Longwell is designed this way and simply takes an RDF source >> and loads it into the triplestore on initialization of the server long >> before users interact with it. >> >> The area that longwell that does initialize when the first user >> interacts with it are the facets that are calculated across the whole >> triplestore, held in memory and presented in the start pages. >> > The first user to view a particular backstaged exhibit will suffer all > that initial cost. Subsequent users will benefit from it. > > Facets found in exhibits can actually be a lot more complicated than > facets in Longwell instances. In Longwell, a facet can only be defined > by a property (an RDF predicate). In Exhibit, it can be defined by an > Exhibit expression. > >>> But you might still have that exhibit shown on your >>> browser, and it's entirely reasonable to want to resume your >>> interaction >>> with it after leaving it alone for a long time. At this point, your UI >>> action (e.g., clicking in a facet) will cause client-side Backstage to >>> call server-side Backstage, who has lost all its states about your >>> interactive session. Server-side Backstage returns a particular error, >>> which causes client-side Backstage to send over its whole state so >>> that >>> server-side Backstage can reinitialize itself and pick up where it has >>> left off. >>> >> >> When I think about our needs at MIT Libraries for Longwell and DSpace, >> the data will always be local or its source very controlled on the >> server side. So the above cases would not be requirements for our >> usage of the application. Though I'm sure such "dynamic loading" might >> be of strong interest for others in the community. >> > Right. I think what you care about is the ability to customize the site > using just HTML rather than hacking Velocity templates, JSP pages, etc. > > Note that a single DSpace instance might still have sub-communities who > want to customize their own front pages, or even users who want > different pages for certain sub-collections. RDF lets users afford > flexible data models, and Exhibit style of UI configuration lets users > afford flexible UIs. > > Or even better, a user might want to combine some DSpace data with her > own data (stored on her web site)... > > David > > _______________________________________________ > General mailing list > [email protected] > http://simile.mit.edu/mailman/listinfo/general > > -- View this message in context: http://www.nabble.com/scaling-up-Exhibit---an-early-experiment-tp15339573p15560503.html Sent from the SIMILE - General mailing list archive at Nabble.com. _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
