Hi David,
Well I had a play, I can't claim to understand what's going on but I presume
that the "backstage" part builds the database and does the indexing.
One problem I have with Exhibit is that some of the data I use is licensed with
the condition that it's OK to publish the data so long as it cannot be
reconstructed. Obviously with Exhibit loading all the data into the local
machine this really restricts what I can release.
I was wondering if you have any thoughts about implementing a more traditional
AJAX client/server type architecture. Where the database is held server-side
and responds to client queries (facet selections) with the restrictions on
other facet values and a selection of the top n items to display. This
delegation of the database processes outside Exhibit would enable control over
limited license data and also obviously the ability to scale up to traditional
large relational databases which can contain millions of items.
N
> Date: Thu, 7 Feb 2008 12:49:11 -0500
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: scaling up Exhibit - an early experiment
>
> Hi all,
>
> Some people have expressed a desire to use Exhibit on larger data sets,
> and I have mentioned that there is an effort to address that need. This
> is not a trivial engineering effort--it'll take months. But I'd like to
> show you a very, very early experiment (codenamed Backstage) to explain
> where we're heading.
>
> Point your Firefox browser at:
> http://people.csail.mit.edu/dfhuynh/misc/backstage-demo.html
> (I will keep this demo up for 1 day only as this is running on my
> own development machine.)
> Note that there are 2383 items (only 20 are displayed, but the facets
> are complete).
>
> Take a look at the HTML source code. You'll see the usual simplicity
> found in exhibits' HTML source code. Right now 2 different APIs are included
>
> <script
> src="http://static.simile.mit.edu/exhibit/api-2.0/exhibit-api.js?autoCreate=false";></script>
> <script
> src="http://dfhuynh.csail.mit.edu:8181/backstage/api/backstage-api.js";></script>
>
> The Backstage API consists of Javascript code as well as Java code
> running on my machine. In the future, the two APIs will be blended
> together so that you'll only need to include exhibit-api.js and set a
> flag, e.g.,
>
> <script
> src="http://static.simile.mit.edu/exhibit/api-2.0/exhibit-api.js?backstage=true";></script>
>
> But for now, the 2 APIs actually serve to make a point. There are 3
> parties involved
> - the data comes from wingerz.com
> - the configuration of the exhibit comes from people.csail.mit.edu
> - the actual computation (think facets) comes from
> dfhuynh.csail.mit.edu:8181
> This is an advanced form of mash-up where you "borrow" data from one
> party (just by linking to it), "delegate" computations to another party,
> and tie it all together with some simple HTML code. "Delegation" is done
> automatically for you, and those computational resources you get for
> free actually include a real database, spawned and configured on the fly
> to meet your needs.
>
> The current performance should be better than Exhibit for this data set,
> but it has not been optimized, especially for several concurrent users,
> and especially because I have an old machine. But it's conceivable that
> we'll have a farm of fast machines all running Backstage, to which
> exhibits with large data sets can delegate automatically.
>
> (I can explain the inner technical workings of Backstage in a subsequent
> email if anyone is interested to know.)
>
> Cheers,
>
> David
>
> _______________________________________________
> General mailing list
> [email protected]
> http://simile.mit.edu/mailman/listinfo/general
_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox.
http://www.searchgamesbox.com
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
