alpha release of exhibit 2.3

[David Karger]

This is to announce an alpha release of an update to the Exhibit 2
codebase, one that I hope will eventually become Exhibit version 2.3. As
Exhibit 3 matures we aim to shift our developments efforts there, but
for the time being the greater maturity of E2 makes it a better testbed
for these updates. This release fixes a number of bugs and also offers
additional functionality; we'd like to see how that functionality gets
used in order to understand what is important to incorporate into E3.

These changes are all live on
http://trunk.simile-widgets.org/exhibit/api, so all you need to do to
try them is link to that API instead of api.simile-widgets.org . Please
do so, and provide feedback on what is working and what isn't.

Major changes include:

* support for new import data formats including xml and html tables
* exhibit data can be embedded directly in html documents
* map view upgraded to use google maps v3 (gmaps key no longer required)
* map view renders icons locally (using canvas) instead of using painter
service
* a new extension supporting wysiwyg inline editing of data displayed in
any exhibit

There are also several bug fixes. Details of these and other changes
can be found at http://people.csail.mit.edu/karger/Exhibit/alpha.html

[David Karger]

Actually timeline is fine; the problem is with timeplot.  If you load timeplot from www instead of trunk, timeline works fine.  I'm working on tracking the reason.

On 1/26/2012 12:19 AM, Contemplative wrote:

Gave this a shot.  Here is what I noticed:

• Timeline does not work 
• TypeError simile-ajax-bundle.js:477,  
• Error adding action {select Timeline view} to history simile-ajax-bundle.js:476
• Uncaught TypeError: Cannot read property '8' of undefined simile-ajax-bundle.js:478
• simile-ajax-bundle.js:458Failed to create view Timeline
• calendar widget(filter) works if you type in a value, but does not seem to allow a start/end date
• -locale.js files are not found (GET http://trunk.simile-widgets.org/exhibit/api/locales/en-US/locale.js 404 (Not Found))

I use chrome on a linux box and am viewing the errors via inspect element.  Did not dig in, but thought I would let you know what a quick look revealed.

You can take a look yourself here -> Example

--
You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simile-widgets/-/sOsF_NTu_CcJ.
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.

[Michael Nosal]

Make sure that you are creating separate bandInfos for each timeline, not passing the same one to each call to create your new Timeline.

The centerVisibleDate depends on the ether being used for the band, and if you pass the same bandInfo objects to multiple timelines, they end up all using the same ether.

You might also find it easier to use a mediator pattern for synchronizing your timelines. You avoid having them refer to each other explicitly and can centralize the logic for how they interact. 

Super-trivial example:

function Mediator(listeners) {

  this._listeners = listeners;

  }

Mediator.prototype.sync = function(date) {

var i = this._listeners.length;

while (i--) {

this._listeners[i].getBand(0).setCenterVisibleDate(date);

}

}

var mediator = new Mediator([TEOI81A2X,XQK3K0LEY,VOY3K0LEW]);

TEOI81A2X.getBand(0).addOnScrollListener(function(band) {

  mediator.sync(band.getCenterVisibleDate());

});

            

XQK3K0LEY.getBand(0).addOnScrollListener(function(band) {

  mediator.sync(band.getCenterVisibleDate());

});

            

VOY3K0LEW.getBand(0).addOnScrollListener(function(band) {

  mediator.sync(band.getCenterVisibleDate());

});

--Mike

On Jan 26, 2012, at 8:45 PM, Jeff Roehl wrote:

TEOI81A2X.getBand(0).addOnScrollListener(function(band) {
Var centerDateXQK3K0LEY = band.getCenterVisibleDate();
XQK3K0LEY.getBand(0).setCenterVisibleDate(centerDateXQK3K0LEY);
});

XQK3K0LEY.getBand(0).addOnScrollListener(function(band) {
Var centerDateVOY3K0LEW = band.getCenterVisibleDate();
VOY3K0LEW.getBand(0).setCenterVisibleDate(centerDateVOY3K0LEW);
});

VOY3K0LEW.getBand(0).addOnScrollListener(function(band) {
Var centerDateTEOI81A2X = band.getCenterVisibleDate();
TEOI81A2X.getBand(0).setCenterVisibleDate(centerDateTEOI81A2X);
});

 

[David Karger]

OK, the timeline problem (due to timeplot) is fixed.
Locale files not loading isn't a problem---it's just what happens when given locales aren't defined. 

[David Karger]

So since this last post three weeks ago the topic of E2.3 release has been silent.  I've checked, and there has been no activity on the code review site.  How can we move to a resolution of this question?  I continue to believe that a solution that meets most objectives is to push in the changes that represent bug fixes and feature stabilizations, while leaving out the changes that add new features we don't want to feel forced into including in 2.3.



On 2/14/2012 7:45 PM, David Karger wrote:

.

On Mon, Feb 13, 2012 at 12:37 PM, David Karger <kar...@mit.edu> wrote:

Stefano, I appreciate your taking the time to propose this process.  However, I don't think it fits the situation.  We are talking about what is probably the final release on the E2 line.   It doesn't really seem like the right time to introduce a new, complex release process for the line. 

This is not a proposal for a every new release... this is a way to fix a current situation in which two lines have been slowly drifting apart. Let's not confuse the two issues.

I believe once the mainlines have been re-aligned, release management can proceed in a much simpler way.

This suggests to me that you expect further releases after this hypothetical one.  My understanding had been that E2 development will halt now that E3 is officially released.

 

Let's turn to practical issues.  The last release occurred in october 2009.  Since then there have been 378 check-ins to the trunk, broadly spread over the intervening two years.  Nobody who has been pulling from svn has raised any concerns about trunk breakage in the intervening two years, so I see no reason to roll-back trunk to that october 2009 state. 

Again, you're twisting my words. My proposal clearly states that the rollback of trunk is just a temporary measure to go back in time where branches were aligned (where E3 and E2.3a split) and go from there so that E3 can realign to a real E2.3.

I may have misunderstood.  I thought you were saying that trunk.simile-widgets.org should go back to serving the 2009 version of exhibit.  I had problems with this because I know of people who link to trunk in order to benefit from some of the changes that have been checked in since 2009.

Now I read that you mean to back-off only to the E3 split.  Which presumably means less commits.  I don't remember when that happened.  I'm still nervous about breaking things for people linked to trunk.

 

Also, it is inconceivable to me that anybody is going to engage any review of this mass of contributions.  

well, if I have 400 commits to the same file, hardly it's going to require 400 times more effort to evaluate whether I want that file or not... and even less likely to generate 400 lines (normally commits cluster around the same hotspots if they are modifications... and if they are pure additions, they are easy to evaluate).

Just to be clear, these aren't all _my_ commits; they are commits by various people tackling quite distinct issues.  I agree that it isn't 400*one commit, but I suspect it's quite a lot of effort.

 

Thus, I believe your proposal essentially boils down to not having another release. 

Well, let's see what happens, here is the review http://codereview.appspot.com/5673046/

 

This is a plausible approach; after all, anyone who wants the new stuff can simply point to trunk.simile-widgets.org .  However, I continue to believe that there is a bunch of value in this content; it disturbs me to withhold that value from those who aren't sophisticated enough regarding development processes to go looking for the trunk. 

It seems to me that Ryan at least was relatively sanguine about a bugfix/compatible release.  Thus, rather than inventing a brand new process, I'd like to propose that we simply agree on what constitutes bugfix/compatible and release that in our usual way. 

-David

On 2/10/2012 9:15 AM, Stefano Mazzocchi wrote:

On Fri, Feb 10, 2012 at 5:51 AM, David Karger <kar...@mit.edu> wrote:

As I tried to indicate in my last email, I'm actually quite sanguine regarding whetever commit process the community evolves going forward.  There's no rush to figure it out and I'm sure I'll be happy to follow it.  In particular if I find it too burdensome I can just stop coding.  Also, this process will be focused on E3, as E2 development is ending.

My *immediate* concern is the code I've *already* developed for *E2* in the absence of any clear commit process.  I'd like to arrive at a decision about its disposition, one that hopefully doesn't involve throwing it all away.  I'm sitting on a (fait accompli) bunch of code that I think will be of use to the current users, so I'd like to incorporate it.

Fair enough, let's get practical and decouple the immediate needs from the need for more explicit governance rules.

Here is what I would do:

1) move the existing svn "trunk" into a branch, say "branches/davidk_2.3a"

2) copy the "tags/2.2.0" release as "trunk"

3) tell people NOT to update their svn if they're running from trunk until this conflict is resolved

4) create a diff between "branches/davidk_2.3a" and the current "trunk" (which is now the latest released exhibit)

5) put the above patch up for review (for example, a very good one that mimics the tool that Google uses internally is http://codereview.appspot.com/, but any public code review places would work)

6) collect suggestions from the community there on what part of this patch should be "pulled" into trunk for an immediate release and what should remain there up for further discussion on alignment with the 3.0 tree, governance and ownership rules, maintenance responsibilities and what not

7) apply the community reviewed patch to trunk, release it as 2.2.1 if there is no added functionality but only bugfixes, 2.3.0 if there are additions in functionality as well but back compatibility is guaranteed...  if it's not back compatible, it shouldn't have made it into the patch in the first place.

8) tell people the harmonization is done and they are free to update from trunk again

8) whatever is left on the floor of the editing room will probably need further discussions on where it should live, although my suggestions would be against further development on a "vendor" branch and rather use the github model instead, and that might require us to move the mainline from svn to git, although it might not be necessary since git can also talk to an svn repository.

The above process would give you increase vitality and freshness in the mainline that you seek and reduce the impedance mismatch between the agreed upon 2.2 -> 3.0 transition path and the currently proposed 2.3a "detour".

Now, granted, the devil is in the details and such a code review might yield consensus that might not fit 100% your needs... at the same time, it will bring confidence to the fact that this community can self-regulate and protect its users interests, however varied they are and will allow you a clear path that can be repeated in the future.

In fact, I would venture to suggest that using a review-then-commit model might be much better suited for this project, considering the variety of interests surrounding it and the different in skillsets in terms of programming and backgrounds in production-quality software engineering.

All the above will sound painfully convoluted, I'm fully aware of that, but I don't see an easier way to resolve the current impasse in ways that help everybody involved.

 

On 2/10/2012 3:33 AM, Stefano Mazzocchi wrote:

Allow me to add my 2c to this discussion, mostly out of personal
experience with having started, mentored and transferred ownership and
control of several open source projects, some of which highly
successful and most of which still in existence to this day.

First, let me say that I see value in both sides of the argument: this
proposed release is indeed a fork (and that is bad) but it's also
injecting new vitality into the project (and that is good).

One of the metrics I've used in the past to evaluate the health of
open source communities is their abilities to survive their original
authors/promoters leaving. DavidH has beent he main contributor for
Exhibit (and various other simile widgets like timeline) and his
participation is very much reduced. I had a much smaller role in
development but a bigger one in project/community management, and my
participation is similarly reduced.

The principal reason why communities implode after the original
authors leave is what I normally think of as "thermal death": without
a converging force, entropy kicks in and when it passes a certain
threshold, the project dilutes its social capital and fails to convert
enough users into development contributions. The process is too
diluted to sustain itself and it decays.

My understanding of Ryan's strong reaction is a resonation to that
perception: David actions are in good faith but represent a clear
signal of entropy increase.... and show a path of entropy increase and
dilution of cohesion and social capital.

The plan to split the release in patches that fix existing broken
behaviors from new functionality is wise and a good step forward, but
the problems Ryan outlines are real and should be taken very
seriously: without an established and meritocratic process for vetting
contributions and granting ownership to vested parties, there is no
way this project will survive thermal death.

Before you think "governance rules" and drafting committees and asking
for a grants to foundations to fund various get-togethers around the
country to make it happen, let me just save you all that problem and
propose you a simple one that would work:

1) use a distributed version control system for contributions where
anybody can push their own tree, and the main line pulls from what the
stakeholders consider appropriate (by simple email voting, lazy
consensus and majority ruling, no veto power).

2) stakeholders can ask new stakeholders to be granted that status by
nomination and majority ruling

So, if the majority of stakeholders believes that logging every action
in every page that embeds exhibit to an MIT server is a worthwhile
feature to have, it will be pulled into the main-line and released
officially... if not, it stays in a side branch, away from where it
can do damage if mis-used or mis-understood.

But at least, by virtue of a public process to propose additions to
the mainline, there is the possibility for review... which is what
David proposal lacks and that is causing Ryan's production engineer
spidey sense to tingle.

I understand why this will not sound appealing to David: why go from
the ability to commit code as needed to a process that is more
difficult, time consuming and potentially less appealing for external
(and shy) contributors?

Because if not this project will splinter in many different "vendor"
branches (one as an MIT research platform, one as a Zepheira product,
one as a Library of Congress publishing system and so on) and the
Exhibit brand will be diluted, users will be confused by the
incompatible codebases, the ability to turn their usage into potential
contributions will be drastically reduced, along with the potential
for each vendor to share maintenance costs with one another.

As a result, the ability to promote Exhibit as a funding substrate,
software product or publishing system respectively will considerably
degrade if unity is not promoted and maintained as a core value.

This is why, if I had to pick a side, I would side with Ryan and
focusing on increasing sustainability instead of increasing momentum:
mostly because a valuable and healthy/sustainable project will find a
way to increase its momentum, while a project that increases momentum
by splintering to shed inertia will have diluted its social capital
with that action, potentially so much that it could go below the
threshold that makes the project appealing and find itself slowing
down its momentum irreversibly.

--
Stefano.

--
Stefano.

[David Karger]

bump.