This release includes both the new client and the server component of Exhibit 3, so you can see how going from a client only collection to a client/server collection will work. The new client is considerably less functional than the current Exhibit 2 client, but will improve over the next few months. We will be posting a timeline for the rest of the year to the Web page soon, so those of you who need to wait for a more stable version or one with a particular feature will have some idea of when to expect that. Over the next few months we'll also create a lot of new documentation, but for now we just have what's in the code and some basic instructions for building the system.
So for those of you who've been waiting, we hope you'll try it out and give us your thoughts! Bugs and feature requests are welcome via GitHub https://github.com/zepheira/exhibit3/ and discussions welcome on this list.
For those interested in seeing some of this work in action. A few early demonstrations of both the new client and the server component of Exhibit 3 can be found at http://databench.zepheira.com/exhibit3/
Thanks!
--
Eric Miller
President, Zepheira "The Art of Data"
http://zepheira.com/ tel:+1.617.395.0229
--
You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group.
To post to this group, send email to simile-...@googlegroups.com.
To unsubscribe from this group, send email to simile-widget...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
Mark wrote about that here:
https://github.com/zepheira/backstage/wiki/Authoring
It's a symbol at this point, for this early release, that we'll refine
going forward.
Right, Ryan.
I'm not sure if Axel's concern is with the requirement that the string
"localhost" be used, or that remote data can't be referenced.
Hopefully the wiki page addresses the latter concern, and for those
reasons I feel it's something that's pretty much set in stone. But if
the concern is with the former consideration, we do have some
flexibility there. We could also use a FQDN so that the URL is
meaningful outside of the context of its hosting server, which might
be useful for, say, data export. But as it's generally an intractable
problem for a given Web server (Backstage in this case) to determine
its externally visible URLs, we'd have to resort to a configuration
option that would let the administrator define it, allowing - as it
does now - Backstage to reject a request for an exhibit to load
non-locally-hosted data.
As always, feedback is welcome.
Mark.