alpha release of exhibit 2.3
David Karger
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
Contemplative
- 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))
David Karger
--
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.
Jeff Roehl
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);
});
Michael Nosal
Jeff Roehl
From: Michael Nosal <mno...@mitre.org>
To: simile-...@googlegroups.com
Cc: "simile-wi...@googlegroups.com" <simile-wi...@googlegroups.com>
Sent: Friday, January 27, 2012 9:03 AM
Subject: Re: [Simile-Widgets] I cant get these timelines to scroll together
--
You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group.
Michael Nosal
Jeff Roehl
martin
I seem to be getting very dark outlines around the Pin Markers (in
Firefox)
A test page is at: http://www.courtenay.ca/parks/index3.html
Another thing I noticed is the polylines and polygons show the "pointy
finger" but they do not show the infowindow when clicking.
which is no big deal as I an using markers anyway but I did have one
map with just polyline and polygons with no Pin markers.
Something which is GREAT is now when zooming in the polylines stay on
top, previously the polylines would get hidden under the polygons
Also I get a script error when opening a streetview (click on a Pin
Marker then click on streetview)
which appears to be that Google Maps API v3 only supports 4 decimal
places in a LatLon ,<toUrlvalue>
I realize this isn't directly related to Exhibit but just thought I
would make a note of it.
Thanks for all the hard work David it's looking awesome!
cheers
Martin
On Jan 24, 11:21 pm, David Karger <kar...@mit.edu> wrote:
> 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.
>
Jeff Roehl
new Timeline.DefaultEventSource();
Timeline.createHotZoneBandInfo({
zones: [{}]
Timeline.createHotZoneBandInfo({
zones: [
{ start: "Jan 07 2012 00:00:00 GMT-0500",
end: "Jan 10 2012 00:00:00 GMT-0500",
magnify: 5,
unit: Timeline.DateTime.YEAR},
{ start: "Oct 01 1980 00:00:00 GMT-0500",
end: "Oct 04 1980 00:00:00 GMT-0500",
magnify: 2,
unit: Timeline.DateTime.MONTH}]
VOY3K0LEW.layout();
/*-------------------------------------------------------*/
Michael Nosal
>> All produce an error on "Var foo"I didn't see this in Firebug, under "Console" -> "Errors".Am I looking in the right place?
Jeff Roehl
Sent: Friday, January 27, 2012 10:54 AM
Subject: Re: [Simile-Widgets] I cant get these timelines to scroll together
David Karger
David Karger
Locale files not loading isn't a problem---it's just what happens when given locales aren't defined.
On 1/26/2012 12:19 AM, Contemplative wrote:
--
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.
David Karger
enable usage logging on your exhibit by setting a ?log=true parameter on
the end of your exhibit-api.js script, ie .../exhibit-api.js?log=true .
This will capture basic usage data off your exhibit (views and facet
values selected) to help us analyze exhibit usage patterns.
Contemplative
Contemplative
- Uncaught TypeError: Cannot call method 'getClosestValidTime' of null
- A
| <div ex:role="view" | |
| ex:label="Moisture Plot" | |
| ex:viewClass="Timeplot" | |
| ex:seriesConnector=".Commodity" | |
| ex:pointTime=".Delivered" | |
| ex:pointValue=".Moisture" | |
| ex:timeGeometry="timeGeometer" | |
| ex:valueGeometry="valueGeometer"> | |
| </div> I think that I would have to break my data into several data sources to get what I want. If I don't filter to a single Commodity, I get pointTimes for every every Commodity on each Commodity. I wonder if it would be worth it to examine making the timeplot work like this instead of having a separate dataSourse for each series? |
Ryan Lee
I am supportive of a maintenance release to Exhibit 2.2.0 (what is
currently deployed) where long standing bugs get fixed, libraries
updated, etc., for those who feel they can't make a switch to 3.0 just
yet. But this proposed alpha changes semantics and adds features. It
is essentially a fork release. And forking releases sucks: parallel and
divergent lines of development get very hard to reconcile, and they
split focus and energy.
Even so, I'd be happy to take a look at a diff for between June and now
to see what fixes could be incorporated into Exhibit 3.0. But I'm not
going to take in changes to the configuration language or other material
that almost certainly does not belong in the core of Exhibit at all.
Your involvement with Exhibit at the research level is incredibly
valuable, don't get me wrong there; I think it could be amazing to have
a constant flow into the Exhibit community of fresh ideas emanating from
your research group. At the same time, how that's been done to date is
at direct odds with one of the cornerstones of making an open source
project successful: gatekeeping for who can get commit access to the
core trunk.
When any of your students can get in to satisfy your group's
requirements but others from the wider community need to actively
demonstrate participation and core competency to receive the same, the
overall quality of the project is rather more harmed than improved, and
the community gets unhelpful signals about how exactly they're involved.
Code that's been generated for research is almost never the same as
code that's been tested and engineered for production, for many good
reasons - but the difference is there nonetheless.
Still, I do believe these competing interests both deserve their place
in the project, and I think they can be reconciled. One of the reasons
we moved to GitHub was to provide a better social model for working on
Exhibit. With GitHub, everybody is working on their own personal fork
for development, even the gatekeepers. It becomes the gatekeepers job
to merge in any changes as submitted by contributors. This way, anybody
can participate - subject to review. The best contributors then
become gatekeepers themselves. Within this model, your students get the
opportunity to both simply work on code and use it as a proving ground
for promotion to gatekeeper, if that's at all their interest.
Ideally, Exhibit 3.0 also makes it easier to write code for Exhibit
without touching its core. I'm sure it could use some refinement with
experience, but given that that's the direction we're moving in, your
students could then write extensions to pursue their ideas, and your
group serve them up as a sort of Exhibit research lab to the community,
the best features and implementations being adopted into Exhibit over time.
This release you propose conflates what is useful in a maintenance
release with what your group's most recent research focus has been. I
do not believe the two should be joined together in one release.
The interim between the prior release and the next shows how little of a
release process we currently have in place as a community, so I suppose
it feels like fair game to just take individual initiative. There's a
release proposal to the community coming up soon to address just that point.
Nobody is going to force you to stop. But please don't issue a fork
release.
David Karger
However, there is one sticky fact that drove me onto the path of an
exhibit 2.3 release: Exhibit 2 is a full-featured system in active use
at a couple thousand sites, while Exhibit 3, due to the limits of what
we received funding to accomplish, is an incomplete upgrade that does
not yet meet the needs of the current E2 users.
As you observe, my proposed 2.3 is a mix of a maintenance and a
"research" release. In the maintenance category we have bugfixes and
the elimination of the painter service dependence in the map view. In
the research category we have logging, embedded data, new input formats,
and data editing.
The rationale for doing maintenance on E2 is that, as observed above, E3
is not yet at a point where current E2 users can transition to it.
Because painter has been a longstanding problem point for E2 users, I
judged it worth improving the quality of their current tool.
In a perfect world, we would have first completed development of E3 to
match E2 capabilities, then added these changes to E3. However, none of
us have the manpower for that, so these needed changes would not have
happened without E2. I judged that the need to have these changes
available *now* trumped the value of shifting all effort to E3.
As for the research component of the release, most of these changes were
again driven by current users. The data editing extension was actually
created by the Ensemble Project at Liverpool University because they
need it for their application of Exhibit in e-learning (and E3 doesn't
yet have what they need). The XML importer was also a request of the
Ensemble project. Embedded data was a specific response for users who
had problems getting their content indexed when the content was on a
linked page, and also ties to the editable data work of the ensemble
project. Logging is indeed something we inserted for our own research
purposes, but it's literally 10 lines of code, not worth attention.
In a sense, the existence of E3 reduced my concern about pushing
experimental changes to E2. We know that eventually E3 will overtake E2
in functionality, and at that point E2 will be decommissioned. E2
therefore becomes a perfect prototyping environment within which to
test-drive ideas that might someday be incorporated in E3 when it
reaches full functionality. Again, those ideas can't be test-driven in
E3 yet, because E3 isn't complete.
To your forking objection, that we "split focus and energy" from E3, I
can only observe how tiny our manpower is at MIT. All of my (as opposed
to ensemble's) contributions to E2.3 represent tinkering at the edges
that I was able to carve out of a small amount of "hobby time". My
contribution to E3 would have been negligible in quantity (and probably
negative in quality---as you say, production code is different).
Essentially, 2.3 is the exhibit "research lab" you recommend at the end
of your note. It isn't a fork because it hasn't taken any meaningful
energy from E3.
I'm happy to continue this discussion, but so far none of the arguments
you've given convince me that there is any negative value in making the
small improvements we've produced available as a new 2.3 release.
Ryan Lee
discuss this.
So I don't think it's on me to convince you why you shouldn't make a
fork release. It's your responsibility to explain why you should. If
you don't see this proposed 2.3 release meeting the definition of a
fork, I can and will explain myself in more depth below, but I'll just
be repeating conventional concepts couched in Exhibit specifics. And
while you go to some lengths to describe the scope, content, and intent
of this material, I feel I should make clear that my objection is to the
act of forking and what its signals.
The reasons you give below for testing out your ideas using Exhibit 2
are spot on. Were I in your position and on a timeline, I would have
done the same and chosen the existing code base over the one that was
just an idea at that time. What I would not have done is make
experimental commits to trunk to satisfy external interests. While it
is a certainty that this experimenting can lead to great improvements to
the code, it is not a certainty that satisfying said external interests
also coincides with making a great release. And it's a release based on
such commit behavior that I'm objecting to.
One of the things I brought up in my last was how your research brings
in new and unknown committers to the main development line without any
prior community participation. With that in mind - how have the
Liverpool group been participating in this open source community?
I mentioned that I thought a great number of the features I see coming
from the research direction don't belong in core from their outset.
Perhaps it would behoove all of us to find some consensus on what core
means. What I'm generally advocating for is that these things begin
their life as extensions external to the project, making their way in to
the Exhibit repository as extensions as the community plays with and
develops them, finally making their way into core if the feature grows
to such a rate of adoption. My ideal resolution to our differences
would be to see a 2.2.1 maintenance-only release and the new features
teased out as extensions for the community to poke at and play with.
Perhaps one way to sum up our differences is that you'd like to make a
release because it's there; I'd prefer you didn't as-is because a lot of
what's there shouldn't be there in the first place.
On forking. You mention your moving to Exhibit 3.0 can happen when its
feature set meets or exceeds Exhibit 2's. Yet you're essentially moving
the goalposts with this proposed 2.3 release. This is one essence of
forking every developer should rightfully despise.
Do you intend for thousands of users to move from 2.2 to 2.3? If not -
and I hope you don't - that suggests this proposed 2.3 release is only
meant for a small circle of adopters. It doesn't sound like it merits a
full, community-wide release. Stranding users on 2.3 to take on a
handful of experimental features while 3.0 marches away from them is
also a distasteful result of forking.
As for not taking any energy away, I think that's contestable, but it's
also only looking in one direction to claim that just because it hasn't
yet doesn't mean it won't in the future. Groups fork from one another
precisely because it does do that.
John
development process. They can help in understanding the status/
direction of the project.
With the release of 2.3, is it the intent that users can simply point
to the 2.3 API and their 2.2-based exhibits would still work? That
was my initial impression although I could be incorrect. Again from a
user perspective, it would be ideal to not have to modify my exhibits
to gain the bug-fixes and enhancements within 2.3. I do not mind a
few additional features with a minor version update, as long as it
doesn't degrade performance and modifications to existing exhibits are
minimal (like almost non-existent.)
At the moment, this is not the case due to the move from Google Maps
v2 to v3. I have a few exhibits with GM v2 javascript in the
mapConstructor function. I do not know if other issues exist in
migrating Exhibit 2.2 to 2.3 (current 2.x trunk)
- John
David Karger
with 2.2 Exhibits defined using html. ie, all the exhibit html tags
should produce exactly the same behavior in 2.3 as in 2.2. If they
don't, it's a bug.
I have added a few new tags/functionality for data import. But since
E2.2 didn't have them, their presence should be irrelevant to 2.2. exhibits.
If you've modified or added to the E2.2. *javascript*, as you are doing
using the map constructor, I can't ensure compatibility.
David Karger
1. It seems we disagree on whether or not the release I am proposing is
a fork. I think this is based on a difference of opinion about whether
a fork is defined by an _action_ or by an _intention_. I do not believe
this is a fork, because there is no intention (and, I believe, no
effect) to divide community effort. I am fully supportive of the
completion of and ultimate migration to E3.
2. You object that "making experimental commitments" may not coincide
with "making a great release". This may be true, but remember that
there is no intention to ever make another "great release" of E2.
Instead, we expect the next great release to be E3. With E2 abandoned,
there seems no downside to releasing some experimental functionality on it.
3. You're right that I believe this code should be released because it
is there. Of course this release could happen in different ways. I
suppose I could put a copy of my code at
http://people.csail.mit.edu/karger/exhibit-api.js , but really why is
this any better? The code still _exists_. Isn't it just as much a fork
that way? On the other hand, the option of deleting my changes seems
damaging, since I think they make the tool better and thus help our
current users---see my point 7 below.
4. "How has the liverpool group participated in the community?" By
creating a pretty cool extension. We might wish that they would
participate more in the discussion group, but I'd rather appreciate
their contribution than feel bad about what they haven't done.
5. To the issue of what should be in core. Note that neither the
data-editor from liverpool nor the map view are "in core". They are
extensions. I suppose we could have asked liverpool to host the data
editing extension somewhere else, but that's putting a big and as far as
I can see unnecessary barrier on the contribution. Similarly the map
extension is outside core. As proof, exhibit and the map extension can
be mixed and matched between 2.2 and trunk: the 2.2 map extension will
run fine with the current trunk (one user is already doing so), and the
trunk map extension should work fine with E2.2 core (though I haven't
tried that mix). I can see some weight to an argument that I should
have created a new extension---mapv3-extension.js . A similar argument
could be made that each data-format importer should be its own script
that must be explicitly included. But such extensions would only be
available to people who explicitly ask for them, which bumps into the
next consideration:
6. I think the really big question is whether, at some point, we should
switch over simile-widgets.org/exhibit/api to use the 2.3 version
instead of 2.2. Obviously, 2.2 will still exist at
api.simile-widget.org/exhibit/2.2.0 , so it isn't a matter of
eliminating something people depends on. But a switchover would mean a
"forced upgrade" for anyone who isn't paying attention to their
exhibits. Is this a good thing or a bad thing? Thinking about the
changes, we have (i) maintenance that should rescue people from bugs
(and painter failures) and (ii) new features that they won't see at all
if they don't choose to use them. On the downside, we have the risk
that I have introduced new bugs, or incompatibilities with certain
customizations people have already made. That would obviously be bad,
which is why I want to take the time to let people test trunk
voluntarily before we do a switchover. I believe that at a certain
point, we will have enough evidence that 2.3 is "safe" to make the
(known) benefits outweigh the (unknown) risks.
7. This also ties to your question, "Do I intend for thousands of users
to move from E2.2 to E2.3"? I believe that the painter issue has caused
widespread problems in the past, and that other bugs have been a general
nuisance, and therefore think there is benefit for the entire community
to make the shift. That's why I think ultimately it will be better for
the default exhibit api to be 2.3. This does have to balanced against
the worry/risk that changes may cause some 2.2 exhibits to stop
working---which is why I want to test for a while before making the switch.
8. Another way to interpret your question is as worrying about the
consequences if many exhibit users adopt the new features like data
import or data editing. I think this would be great! It would provide
a very strong signal that these things are important to incorporate into
E3. Perhaps this is where you worry about leaving users "stranded" in
the move to E3---that they will have become dependent on those features
and won't be able to move. But again, I don't buy the argument that we
should withhold something from our current users just because we might
not be able to provide it in the future.
9. More generally, I think our differences may reflect an argument that
has played out often in the past: in medicine, should we be directing
our money towards treating poor current sufferers from a disease, or
should we be investing in research that may ultimately yield a complete
cure? For us, this translates to "should we be doing things that
benefit the current *users* of the exhibit codebase, or should we be
investing in a development process that will yield a better development
community in the long term." I can accept the argument that effort
invested in helping current exhibit users (through maintenance or new
features) might be effort taken away from long-term development
community building. But by the same token, investing effort in
long-term development can detract from solving the problems that current
users face. And I think the answer is the same as it for medicine: both
the arguments are true, but neither is definitive. We value both
investments---in current benefit and in future benefit---and really
don't have the foresight necessary to understand the optimal allocation
between them. So we do both.
10. To the question of moving the goalposts, I am happy to commit, once
E3 is otherwise feature complete, to porting the E2 changes I made into
E3. Although, as I remarked before, you probably don't want any code
contributions from a bad engineer like me into a production quality system!
Ryan Lee
> OK, I'm going to try to unpack a few different arguments.
I'll respond inline below, but I should note that there are several
other things going on in this thread that have wider repercussions
within this community than whether this proposed release goes forward.
First and foremost is closing all back doors into the privilege of
becoming a code committer on the project. While I go on more about this
under your point 4 and others, I'd like to hear your response. I've
brought it up in every message I've sent and am bringing it up again. I
do very much believe this general policy will have little to no impact
on your research goals and methods, but if you think differently, that
will have to be addressed.
The second, as I think we've teased out in these discussions, is how
best to develop and present new extension level features to users. It's
becoming clear to me that most extensions should be released on their
own schedule from the core of Exhibit. To date, the ones colocated with
Exhibit have been in lockstep. Perhaps there is a subset of these that
should continue to be held in sync with core, but there may be some that
we've got that could be cut loose to follow their own development flow.
This suggests a bit of work is needed for extensions to identify which
version of core they're meant to work with.
> 1. It seems we disagree on whether or not the release I am proposing is
> a fork. I think this is based on a difference of opinion about whether
> a fork is defined by an _action_ or by an _intention_. I do not believe
> this is a fork, because there is no intention (and, I believe, no
> effect) to divide community effort. I am fully supportive of the
> completion of and ultimate migration to E3.
It's good to hear your intentions restated in this form; nevertheless,
forking *is* an action. Well-intentioned forks still have all the
consequences of forking code. It appears we are still at odds on what
it means.
While I've mostly avoided discussing the specifics of this proposed
release to avoid ratholes on debating the relative merits of each, I
will pick on two to illustrate my point. You created ex:getter and
ex:parser for importers, a design problem I also noted and resolved in
3.0 - completely differently (via an API). There might be a way to
automatically resolve it when the two are joined, or it might be a
nightmare that forces every importer developer to implement in such a
way as to answer to both. You never intended it, but there is a
potential mire to bog down in if both are out there as official solutions.
I would also pick on the current implementation of logging. It took the
easy way out and is as a result way out of line. It should not be in
core. It should instead be made into an extension users can load off of
a csail.mit.edu server since it already is opt-in and requires editing
the HTML. The Exhibit parameters introduced with logging should not
exist in core. I am rather certain it is difficult and ugly to do what
I just suggested in Exhibit 2. It should be trivial in Exhibit 3. Put
a hold on introducing your research team's logging to a release; it
definitely doesn't belong there. (I haven't been tracking this closely,
but you may also want to warn Exhibit authors using logging to warn
their own users that their activity is being recorded).
> 2. You object that "making experimental commitments" may not coincide
> with "making a great release". This may be true, but remember that
> there is no intention to ever make another "great release" of E2.
> Instead, we expect the next great release to be E3. With E2 abandoned,
> there seems no downside to releasing some experimental functionality on it.
What I was saying too backhandedly was that experimental commits
probably make for a terrible point release, not that I think Exhibit 2
now needs a great release to have a release.
It's rather important to point out that to date, Exhibit releases have
been of the type that suggest if a feature is in, it's in it to stay.
That's quite contrary to experimenting. Experiments are allowed to fail
in order to provide interesting information. Releases of the type
Exhibit has undergone have not seemed to me to be intended for
experimenting, where failed features get removed. Releasing web-based
services might carry some extra caveats about going too experimental, too.
I should note on the side that I do believe in releasing early and often
and unknowingly adding bugs and making mistakes to further a project -
as long as there is appropriate gatekeeping in place. And maybe some
test harnesses.
> 3. You're right that I believe this code should be released because it
> is there. Of course this release could happen in different ways. I
> suppose I could put a copy of my code at
> http://people.csail.mit.edu/karger/exhibit-api.js , but really why is
> this any better? The code still _exists_. Isn't it just as much a fork
> that way? On the other hand, the option of deleting my changes seems
> damaging, since I think they make the tool better and thus help our
> current users---see my point 7 below.
There's a rather substantive difference (of thousands of existing users)
between api.simile-widgets.org and people.csail.mit.edu/karger.
Everybody is already free to "fork" hosting in the sense you describe,
I'm not sure it pertains to this discussion. What you're proposing is
an *official* fork release.
> 4. "How has the liverpool group participated in the community?" By
> creating a pretty cool extension. We might wish that they would
> participate more in the discussion group, but I'd rather appreciate
> their contribution than feel bad about what they haven't done.
That's a false dichotomy. One of the points I'll keep drumming at you
is that people who aren't yet part of this community can't be let in to
make commits without first entering into it through the front door,
otherwise it doesn't work as a community. That fact doesn't diminish
their eagerness to contribute or the usefulness of their work; it means
that work never should have come in the back door through you (or any of
us). Officially releasing a non/back door participant's work is not a
good signal to the rest of the community, the way letting unknown
committers commit to trunk is not a good signal - it's just a lot bigger
of a signal.
In the future when newcomers approach any of us (or, I suppose, are
approached by us) regarding improving Exhibit, I hope our line is
something like, "Excellent, join the list, fork on GitHub, and send in
your pull requests" - just like everybody else.
> 5. To the issue of what should be in core. Note that neither the
> data-editor from liverpool nor the map view are "in core". They are
I am aware of that. That's why I don't think it would so burdensome to
shift it out of a release.
> extensions. I suppose we could have asked liverpool to host the data
> editing extension somewhere else, but that's putting a big and as far as
> I can see unnecessary barrier on the contribution. Similarly the map
> extension is outside core. As proof, exhibit and the map extension can
> be mixed and matched between 2.2 and trunk: the 2.2 map extension will
> run fine with the current trunk (one user is already doing so), and the
> trunk map extension should work fine with E2.2 core (though I haven't
> tried that mix). I can see some weight to an argument that I should
> have created a new extension---mapv3-extension.js . A similar argument
> could be made that each data-format importer should be its own script
> that must be explicitly included. But such extensions would only be
> available to people who explicitly ask for them, which bumps into the
> next consideration:
Part of forming a community does involve barriers. Yes, it's open to
the world, but membership requires some proof of interest and capacity.
It's as low as it can get, but it's there. Were this group not
suddenly granted access to trunk carte blanche, they would have
solicited community input on the extension - by putting it up and
hosting it somewhere. If that's about the measure of how things will
progress in the future, then I'm asking you to not make special
exceptions for it now.
> 6. I think the really big question is whether, at some point, we should
> switch over simile-widgets.org/exhibit/api to use the 2.3 version
> instead of 2.2. Obviously, 2.2 will still exist at
> api.simile-widget.org/exhibit/2.2.0 , so it isn't a matter of
> eliminating something people depends on. But a switchover would mean a
> "forced upgrade" for anyone who isn't paying attention to their
> exhibits. Is this a good thing or a bad thing? Thinking about the
> changes, we have (i) maintenance that should rescue people from bugs
> (and painter failures) and (ii) new features that they won't see at all
> if they don't choose to use them. On the downside, we have the risk
> that I have introduced new bugs, or incompatibilities with certain
> customizations people have already made. That would obviously be bad,
> which is why I want to take the time to let people test trunk
> voluntarily before we do a switchover. I believe that at a certain
> point, we will have enough evidence that 2.3 is "safe" to make the
> (known) benefits outweigh the (unknown) risks.
You understate the impact of new features, not all of which are outside
of core. The code is there whether one particular user puts it into
play or not. The fact that the code is there binds you to its
existence, and you have to wrestle with the difficult questions of how
to deal with its existence in the future.
For an outside example, HTML5 gets to wrestle with XHTML/XML namespaces.
It's not at all an easy matter to resolve, because lots of people ended
up adopting namespaces, and HTML5 isn't XML. Some people are simply
never going to leave XHTML because of it. The current solution is that
a very few "xmlns:xx" attributes exist, for which the prefix "xmlns:" is
meaningless and just part of the name. I'd like to avoid that kind of
thing.
> 7. This also ties to your question, "Do I intend for thousands of users
> to move from E2.2 to E2.3"? I believe that the painter issue has caused
> widespread problems in the past, and that other bugs have been a general
> nuisance, and therefore think there is benefit for the entire community
> to make the shift. That's why I think ultimately it will be better for
> the default exhibit api to be 2.3. This does have to balanced against
> the worry/risk that changes may cause some 2.2 exhibits to stop
> working---which is why I want to test for a while before making the switch.
Your answer revolves around maintenance, to which I never objected. I
haven't made it clear (avoiding specifics, etc.), but I've considered
your work on the map view to be welcome maintenance.
> 8. Another way to interpret your question is as worrying about the
> consequences if many exhibit users adopt the new features like data
> import or data editing. I think this would be great! It would provide
> a very strong signal that these things are important to incorporate into
> E3. Perhaps this is where you worry about leaving users "stranded" in
> the move to E3---that they will have become dependent on those features
> and won't be able to move. But again, I don't buy the argument that we
> should withhold something from our current users just because we might
> not be able to provide it in the future.
Not really. You clearly don't need to make a release to make these
things available to people as they're already testing them. Your
argument cuts both ways; if it isn't in the release, it can still be
provided for users to try out. My argument was never to completely
shutter that work - it was to avoid conflating it with a release by
carving it out of one.
> 9. More generally, I think our differences may reflect an argument that
> has played out often in the past: in medicine, should we be directing
> our money towards treating poor current sufferers from a disease, or
> should we be investing in research that may ultimately yield a complete
> cure? For us, this translates to "should we be doing things that
> benefit the current *users* of the exhibit codebase, or should we be
> investing in a development process that will yield a better development
> community in the long term." I can accept the argument that effort
> invested in helping current exhibit users (through maintenance or new
> features) might be effort taken away from long-term development
> community building. But by the same token, investing effort in
> long-term development can detract from solving the problems that current
> users face. And I think the answer is the same as it for medicine: both
> the arguments are true, but neither is definitive. We value both
> investments---in current benefit and in future benefit---and really
> don't have the foresight necessary to understand the optimal allocation
> between them. So we do both.
Again, I have repeatedly (and already above) stated I have no problems
with a maintenance release. This analogy doesn't really seem to get at
our differences to me. You'll pardon if I don't offer a counter
analogy, none come to mind at present.
> 10. To the question of moving the goalposts, I am happy to commit, once
> E3 is otherwise feature complete, to porting the E2 changes I made into
> E3. Although, as I remarked before, you probably don't want any code
> contributions from a bad engineer like me into a production quality system!
It may not necessarily be a matter of simple porting. I'm glad you're
making a commitment to it. I am not certain the direction you've moved
in along the 2 line allows you to simply modify your code to achieve
compatibility. If you don't create the expectations a formal and
official release entail, you will find yourself free to simply drop or
reformulate at will anything that doesn't come over naturally.
David Karger
On 2/4/2012 8:15 PM, Ryan Lee wrote:
> On 2012-02-03 11:42 , David Karger wrote:
>> OK, I'm going to try to unpack a few different arguments.
> I'll respond inline below, but I should note that there are several
> other things going on in this thread that have wider repercussions
> within this community than whether this proposed release goes forward.
>
> First and foremost is closing all back doors into the privilege of
> becoming a code committer on the project. While I go on more about this
> under your point 4 and others, I'd like to hear your response. I've
> brought it up in every message I've sent and am bringing it up again. I
> do very much believe this general policy will have little to no impact
> on your research goals and methods, but if you think differently, that
> will have to be addressed.
I am comfortable with any community-determined process for admitting
core committers. To date there hasn't been one, so I've been left to
make decisions on my own.
>
> The second, as I think we've teased out in these discussions, is how
> best to develop and present new extension level features to users. It's
> becoming clear to me that most extensions should be released on their
> own schedule from the core of Exhibit. To date, the ones colocated with
> Exhibit have been in lockstep. Perhaps there is a subset of these that
> should continue to be held in sync with core, but there may be some that
> we've got that could be cut loose to follow their own development flow.
> This suggests a bit of work is needed for extensions to identify which
> version of core they're meant to work with.
This discussion is highlighting a worrying tension between the developer
community and the user community. I hope we can figure out a way to
release this tension. You misread my analogy to medical research; it
was not trying to contrast maintenance releases from experimental
releases, but rather was trying to contrast work aimed at future benefit
(careful gatekeeping to build a robust development community) from work
aimed at addressing immediate needs of current users.
When I saw David's earliest version of Exhibit, an aspect that really
inspired me was the idea that here is something that non-developer, HTML
novice can use. And that is where I have continued to focus my energy.
I worry about any changes that will impact such naive users of exhibit.
It's fine to tell a developer "well, take this core from this site, then
you can combine with this version of this extension from that site (but
not another version), and if you want this functionality I'm sure that
there's an extension for that somewhere else if you can find it". But
that's a complete non-starter for naive users. I think there's a
noticeable gap be telling such people "put type='application/xml' in
your link tag" and "to import xml you need to include such and such
script in your document". I foresee us heading in the direction of
jquery-ui, which has its own web application that lets you build and
download to host your own custom script bundle. Fine for developers,
but a disaster for naive users.
>
>> 1. It seems we disagree on whether or not the release I am proposing is
>> a fork. I think this is based on a difference of opinion about whether
>> a fork is defined by an _action_ or by an _intention_. I do not believe
>> this is a fork, because there is no intention (and, I believe, no
>> effect) to divide community effort. I am fully supportive of the
>> completion of and ultimate migration to E3.
> It's good to hear your intentions restated in this form; nevertheless,
> forking *is* an action. Well-intentioned forks still have all the
> consequences of forking code. It appears we are still at odds on what
> it means.
>
> While I've mostly avoided discussing the specifics of this proposed
> release to avoid ratholes on debating the relative merits of each, I
> will pick on two to illustrate my point. You created ex:getter and
> ex:parser for importers, a design problem I also noted and resolved in
> 3.0 - completely differently (via an API). There might be a way to
> automatically resolve it when the two are joined, or it might be a
> nightmare that forces every importer developer to implement in such a
> way as to answer to both. You never intended it, but there is a
> potential mire to bog down in if both are out there as official solutions.
As a minor point, I am suspicious of anything that is solved "via an
API" since (given my interests) that suggests it will not be accessible
to naive users.
>
> I would also pick on the current implementation of logging. It took the
> easy way out and is as a result way out of line. It should not be in
> core. It should instead be made into an extension users can load off of
> a csail.mit.edu server since it already is opt-in and requires editing
> the HTML. The Exhibit parameters introduced with logging should not
> exist in core. I am rather certain it is difficult and ugly to do what
> I just suggested in Exhibit 2. It should be trivial in Exhibit 3. Put
> a hold on introducing your research team's logging to a release; it
> definitely doesn't belong there. (I haven't been tracking this closely,
> but you may also want to warn Exhibit authors using logging to warn
> their own users that their activity is being recorded).
Here I have to disagree on technical grounds. I can see absolutely no
way to accomplish logging without tinkering core. We're trying to
record actions taken in the exhibit core. To do that from outside core
would require a script that, after loading core, redefines every single
logged function inside core to first log and then call the in-core
function. This seems incredibly fragile and will break any time
somebody changes core.
To the separate concern of adding exhibit parameters, I am comfortable
changing the way we _activate_ the logging functionality, replacing the
current parameter setting with a script, e.g. <script
src="http://csail/logger.js"> which would turn on the logging.
To the question of warning users, note that we chose an opt-in mechanism
because we considered it very much the role of the web author to decide
whether to log. Subsequently, the web author has their own decision to
make about whether to give the page's visitors a choice about
logging---however, this is exactly the same decision as they make when
they decide to put the google analytics urchin into their pages, and I
don't think _anyone_ bothers to ask permission of that from their
users. The logger collects exactly the same kind of data as those
analytics tools; in fact if exhibit was server based and generated a new
page for each interface action, we could just use google analytics to
gather the same data.
>
>> 2. You object that "making experimental commitments" may not coincide
>> with "making a great release". This may be true, but remember that
>> there is no intention to ever make another "great release" of E2.
>> Instead, we expect the next great release to be E3. With E2 abandoned,
>> there seems no downside to releasing some experimental functionality on it.
> What I was saying too backhandedly was that experimental commits
> probably make for a terrible point release, not that I think Exhibit 2
> now needs a great release to have a release.
>
> It's rather important to point out that to date, Exhibit releases have
> been of the type that suggest if a feature is in, it's in it to stay.
> That's quite contrary to experimenting. Experiments are allowed to fail
> in order to provide interesting information. Releases of the type
> Exhibit has undergone have not seemed to me to be intended for
> experimenting, where failed features get removed. Releasing web-based
> services might carry some extra caveats about going too experimental, too.
>
> I should note on the side that I do believe in releasing early and often
> and unknowingly adding bugs and making mistakes to further a project -
> as long as there is appropriate gatekeeping in place. And maybe some
> test harnesses.
I agree that past releases have been more reflective of future
commitment. However, as I said, we have all made quite clear that E3 is
the future of exhibit.
>> 3. You're right that I believe this code should be released because it
>> is there. Of course this release could happen in different ways. I
>> suppose I could put a copy of my code at
>> http://people.csail.mit.edu/karger/exhibit-api.js , but really why is
>> this any better? The code still _exists_. Isn't it just as much a fork
>> that way? On the other hand, the option of deleting my changes seems
>> damaging, since I think they make the tool better and thus help our
>> current users---see my point 7 below.
> There's a rather substantive difference (of thousands of existing users)
> between api.simile-widgets.org and people.csail.mit.edu/karger.
> Everybody is already free to "fork" hosting in the sense you describe,
> I'm not sure it pertains to this discussion. What you're proposing is
> an *official* fork release.
If we can resolve this whole debate by serving the release from
simile-widgets.org/exhibit-mit , or by reactivating simile.mit.edu and
hosting the new release there, I'm all for it. Of course, I'll
recommend everyone switch to it, since I think it's better. And we'll
probably need a separate copy of the documentation wiki, to describe the
features that aren't in the official release. And a separate web-site
to which I can direct people who are interest in exhibit and may want to
use the added features. This seems much more forky to me than anything
we've yet discussed.
>> 4. "How has the liverpool group participated in the community?" By
>> creating a pretty cool extension. We might wish that they would
>> participate more in the discussion group, but I'd rather appreciate
>> their contribution than feel bad about what they haven't done.
> That's a false dichotomy. One of the points I'll keep drumming at you
> is that people who aren't yet part of this community can't be let in to
> make commits without first entering into it through the front door,
> otherwise it doesn't work as a community. That fact doesn't diminish
> their eagerness to contribute or the usefulness of their work; it means
> that work never should have come in the back door through you (or any of
> us). Officially releasing a non/back door participant's work is not a
> good signal to the rest of the community, the way letting unknown
> committers commit to trunk is not a good signal - it's just a lot bigger
> of a signal.
>
> In the future when newcomers approach any of us (or, I suppose, are
> approached by us) regarding improving Exhibit, I hope our line is
> something like, "Excellent, join the list, fork on GitHub, and send in
> your pull requests" - just like everybody else.
So this helps me understand another issue to tease apart. Liverpool
produced an *extension* and never touched the exhibit core. In fact,
all I was thinking about when I provided commit access was that this
simplified the *hosting* of the extension on simile-widgets.org. I
understand that this had *development authority* implications I wasn't
considering. I'd be perfectly happy to resolve them by moving the
extension to a different subversion repository. However, in the
interest of keeping things simple for those naive users, I would still
want to *serve* the extension from simile-widgets.org.
And why simile-widgets.org instead of csail.mit.edu/karger ?
Resources. I'm happy to leverage the fact the MIT libraries are
maintaining a well-run, high capacity server that can deliver our
scripts. Kenzie may disapprove of my taking advantage of MIT libraries
this way, but as long as they are willing to do the management, I don't
have to find the resources to do it.
And some people may never leave exhibit 2 because they are using some
feature only it has. But in the meantime they have a feature they can
use. Again, this comes back to the medicine metaphor. If I can provide
this needed feature to users now, when it's impossible to provide in E3,
then I'm helping them *now*. That is a different but valuable
contribution distinct from things that might help them *later*.
OK, it seems that if I just leave everything as it is, with people
needing the new features linking to trunk.simile-widgets.org , then
everything is fine?
Ryan Lee
received a response, I've removed those under the assumption there's
nothing further to discuss on them.
On 2012-02-04 21:57 , David Karger wrote:
> On 2/4/2012 8:15 PM, Ryan Lee wrote:
>> On 2012-02-03 11:42 , David Karger wrote:
>>> OK, I'm going to try to unpack a few different arguments.
>> I'll respond inline below, but I should note that there are several
>> other things going on in this thread that have wider repercussions
>> within this community than whether this proposed release goes forward.
>>
>> First and foremost is closing all back doors into the privilege of
>> becoming a code committer on the project. While I go on more about this
>> under your point 4 and others, I'd like to hear your response. I've
>> brought it up in every message I've sent and am bringing it up again. I
>> do very much believe this general policy will have little to no impact
>> on your research goals and methods, but if you think differently, that
>> will have to be addressed.
>
> I am comfortable with any community-determined process for admitting
> core committers. To date there hasn't been one, so I've been left to
> make decisions on my own.
Great. I believe there will be more on this topic in the future.
>> The second, as I think we've teased out in these discussions, is how
>> best to develop and present new extension level features to users. It's
>> becoming clear to me that most extensions should be released on their
>> own schedule from the core of Exhibit. To date, the ones colocated with
>> Exhibit have been in lockstep. Perhaps there is a subset of these that
>> should continue to be held in sync with core, but there may be some that
>> we've got that could be cut loose to follow their own development flow.
>> This suggests a bit of work is needed for extensions to identify which
>> version of core they're meant to work with.
> This discussion is highlighting a worrying tension between the developer
> community and the user community. I hope we can figure out a way to
> release this tension. You misread my analogy to medical research; it
> was not trying to contrast maintenance releases from experimental
> releases, but rather was trying to contrast work aimed at future benefit
> (careful gatekeeping to build a robust development community) from work
> aimed at addressing immediate needs of current users.
My apologies for misreading it. I'm not sure careful gatekeeping makes
sense as a contrast to addressing immediate needs outside of this
particular, odd moment in time. I'd prefer to start looking to intended
patterns as guidance.
I also wouldn't classify releasing new features that change the core as
necessarily addressing the immediate needs of current users. It's a bit
much to claim releasing a feature some have asked for as equal to fixing
long standing bugs that negatively affect many existing users in terms
of meeting needs.
There should be a process for moving work done in the developer
community into the core for the user community. If we're going to
continue disagreeing on terms, then we also disagree on what constitutes
immediacy and needs.
> When I saw David's earliest version of Exhibit, an aspect that really
> inspired me was the idea that here is something that non-developer, HTML
> novice can use. And that is where I have continued to focus my energy.
> I worry about any changes that will impact such naive users of exhibit.
> It's fine to tell a developer "well, take this core from this site, then
> you can combine with this version of this extension from that site (but
> not another version), and if you want this functionality I'm sure that
> there's an extension for that somewhere else if you can find it". But
> that's a complete non-starter for naive users. I think there's a
> noticeable gap be telling such people "put type='application/xml' in
> your link tag" and "to import xml you need to include such and such
> script in your document". I foresee us heading in the direction of
> jquery-ui, which has its own web application that lets you build and
> download to host your own custom script bundle. Fine for developers,
> but a disaster for naive users.
A process is intended to move those features that are best suited for
everybody into core so that, at some point, the barriers get reduced to
an absolute minimum. Those who can keep up with the necessary moving
parts of material under active development are also those who don't need
extra handholding. If the features are good, everybody should
eventually have full access to them.
By avoiding putting undercooked features into releases, you do what you
can to avoid getting stuck in a miasma of simultaneously trying to
support and back out released problems. That's no guarantee, to be
sure, but it helps.
Your prediction is hard to see coming true given we don't aim for it.
You don't accidentally fall into that kind of architecture (and jQuery
UI is quite purposefully modular, for good or ill). Nevertheless,
there's no reason to assume every version of an extension is fully
compatible with every version of core. Some mechanics around that are
going to be necessary as part of the code base maturing.
>>> 1. It seems we disagree on whether or not the release I am proposing is
>>> a fork. I think this is based on a difference of opinion about whether
>>> a fork is defined by an _action_ or by an _intention_. I do not believe
>>> this is a fork, because there is no intention (and, I believe, no
>>> effect) to divide community effort. I am fully supportive of the
>>> completion of and ultimate migration to E3.
>> It's good to hear your intentions restated in this form; nevertheless,
>> forking *is* an action. Well-intentioned forks still have all the
>> consequences of forking code. It appears we are still at odds on what
>> it means.
>>
>> While I've mostly avoided discussing the specifics of this proposed
>> release to avoid ratholes on debating the relative merits of each, I
>> will pick on two to illustrate my point. You created ex:getter and
>> ex:parser for importers, a design problem I also noted and resolved in
>> 3.0 - completely differently (via an API). There might be a way to
>> automatically resolve it when the two are joined, or it might be a
>> nightmare that forces every importer developer to implement in such a
>> way as to answer to both. You never intended it, but there is a
>> potential mire to bog down in if both are out there as official
>> solutions.
> As a minor point, I am suspicious of anything that is solved "via an
> API" since (given my interests) that suggests it will not be accessible
> to naive users.
The API is for those writing importers. Maybe someone should take a
moment to see where the differences actually are, but to step around
that, the fact that this engenders discussion is a mark against making a
release with it included in full.
>> I would also pick on the current implementation of logging. It took the
>> easy way out and is as a result way out of line. It should not be in
>> core. It should instead be made into an extension users can load off of
>> a csail.mit.edu server since it already is opt-in and requires editing
>> the HTML. The Exhibit parameters introduced with logging should not
>> exist in core. I am rather certain it is difficult and ugly to do what
>> I just suggested in Exhibit 2. It should be trivial in Exhibit 3. Put
>> a hold on introducing your research team's logging to a release; it
>> definitely doesn't belong there. (I haven't been tracking this closely,
>> but you may also want to warn Exhibit authors using logging to warn
>> their own users that their activity is being recorded).
> Here I have to disagree on technical grounds. I can see absolutely no
> way to accomplish logging without tinkering core. We're trying to
> record actions taken in the exhibit core. To do that from outside core
> would require a script that, after loading core, redefines every single
> logged function inside core to first log and then call the in-core
> function. This seems incredibly fragile and will break any time
> somebody changes core.
Like I said, ugly in Exhibit 2, likely trivial in Exhibit 3.
https://github.com/zepheira/exhibit3/wiki/Scripted-Event-API
If there are events missing, do suggest additional useful ones.
As I have stated, I don't believe logging code belongs in core at all,
in any version.
> To the separate concern of adding exhibit parameters, I am comfortable
> changing the way we _activate_ the logging functionality, replacing the
> current parameter setting with a script, e.g. <script
> src="http://csail/logger.js"> which would turn on the logging.
That's certainly a step in a more agreeable direction, but presumably
the response to being activated is still present in core; this would
push it to a different level but is still problematic in terms of
presenting an interface that requires future commitment. And it still
leaves the logging code there.
> To the question of warning users, note that we chose an opt-in mechanism
> because we considered it very much the role of the web author to decide
> whether to log. Subsequently, the web author has their own decision to
> make about whether to give the page's visitors a choice about
> logging---however, this is exactly the same decision as they make when
> they decide to put the google analytics urchin into their pages, and I
> don't think _anyone_ bothers to ask permission of that from their
> users. The logger collects exactly the same kind of data as those
> analytics tools; in fact if exhibit was server based and generated a new
> page for each interface action, we could just use google analytics to
> gather the same data.
Logging every interaction with Exhibit is pretty different from
analyzing visitor traffic (which, though obvious to anybody who's seen a
web server log, is still spelled out in P3P as a privacy disclosure).
Drilling into this topic further seems tangential. Again, my interest
was not in debating any specific feature. My point is that these impose
fork-like burdens on Exhibit 3 that would not exist if they weren't
included in a release, regardless of how the release is positioned.
>>> 2. You object that "making experimental commitments" may not coincide
>>> with "making a great release". This may be true, but remember that
>>> there is no intention to ever make another "great release" of E2.
>>> Instead, we expect the next great release to be E3. With E2 abandoned,
>>> there seems no downside to releasing some experimental functionality
>>> on it.
>> What I was saying too backhandedly was that experimental commits
>> probably make for a terrible point release, not that I think Exhibit 2
>> now needs a great release to have a release.
>>
>> It's rather important to point out that to date, Exhibit releases have
>> been of the type that suggest if a feature is in, it's in it to stay.
>> That's quite contrary to experimenting. Experiments are allowed to fail
>> in order to provide interesting information. Releases of the type
>> Exhibit has undergone have not seemed to me to be intended for
>> experimenting, where failed features get removed. Releasing web-based
>> services might carry some extra caveats about going too experimental,
>> too.
>>
>> I should note on the side that I do believe in releasing early and often
>> and unknowingly adding bugs and making mistakes to further a project -
>> as long as there is appropriate gatekeeping in place. And maybe some
>> test harnesses.
> I agree that past releases have been more reflective of future
> commitment. However, as I said, we have all made quite clear that E3 is
> the future of exhibit.
But that doesn't absolve the apparent future commitment implicit in an
Exhibit 2 release for Exhibit 3.
>>> 3. You're right that I believe this code should be released because it
>>> is there. Of course this release could happen in different ways. I
>>> suppose I could put a copy of my code at
>>> http://people.csail.mit.edu/karger/exhibit-api.js , but really why is
>>> this any better? The code still _exists_. Isn't it just as much a fork
>>> that way? On the other hand, the option of deleting my changes seems
>>> damaging, since I think they make the tool better and thus help our
>>> current users---see my point 7 below.
>> There's a rather substantive difference (of thousands of existing users)
>> between api.simile-widgets.org and people.csail.mit.edu/karger.
>> Everybody is already free to "fork" hosting in the sense you describe,
>> I'm not sure it pertains to this discussion. What you're proposing is
>> an *official* fork release.
> If we can resolve this whole debate by serving the release from
> simile-widgets.org/exhibit-mit , or by reactivating simile.mit.edu and
> hosting the new release there, I'm all for it. Of course, I'll
> recommend everyone switch to it, since I think it's better. And we'll
> probably need a separate copy of the documentation wiki, to describe the
> features that aren't in the official release. And a separate web-site
> to which I can direct people who are interest in exhibit and may want to
> use the added features. This seems much more forky to me than anything
> we've yet discussed.
I would rather avoid a fork regardless of its degree of fork-iness.
There are ways forward that don't requiring forking of any kind.
simile-widgets.org carries more to it than simply hosting. That code
committed to the master branch is also going to be served at the
canonical URL seems to be a consequence of ease of deployment. I'm not
really convinced hosting static JavaScript is a so big a barrier to
developers, though perhaps there's a reasonable way to formulate Exhibit
lab hosting on simile-widgets independent of revision control.
Given you have to add a script tag to use the extensions, at least, I
don't see how serving from simile-widgets makes things all that more
simple for authors.
> And why simile-widgets.org instead of csail.mit.edu/karger ?
> Resources. I'm happy to leverage the fact the MIT libraries are
> maintaining a well-run, high capacity server that can deliver our
> scripts. Kenzie may disapprove of my taking advantage of MIT libraries
> this way, but as long as they are willing to do the management, I don't
> have to find the resources to do it.
>>> 6. I think the really big question is whether, at some point, we should
I very much see your point that not sacrificing helping users now for a
fuzzy future is a good thing to do. The problem is that I don't agree
that everything you intend to release is an unmitigated help to users or
to other developers.
>>> 8. Another way to interpret your question is as worrying about the
>>> consequences if many exhibit users adopt the new features like data
>>> import or data editing. I think this would be great! It would provide
>>> a very strong signal that these things are important to incorporate into
>>> E3. Perhaps this is where you worry about leaving users "stranded" in
>>> the move to E3---that they will have become dependent on those features
>>> and won't be able to move. But again, I don't buy the argument that we
>>> should withhold something from our current users just because we might
>>> not be able to provide it in the future.
>> Not really. You clearly don't need to make a release to make these
>> things available to people as they're already testing them. Your
>> argument cuts both ways; if it isn't in the release, it can still be
>> provided for users to try out. My argument was never to completely
>> shutter that work - it was to avoid conflating it with a release by
>> carving it out of one.
> OK, it seems that if I just leave everything as it is, with people
> needing the new features linking to trunk.simile-widgets.org , then
> everything is fine?
This is a bit terse for me to parse what you mean. It sounds to me like
it's about not making a Exhibit 2 release after all; was that what you
meant?
David Karger
at, as you say, "this particular, odd moment in time". It has broadened
to cover much philosophy germane to long-term planning of our
commit/release process. But I think it will simplify to split
consideration of the present "odd moment" from the future planning.
Perhaps we can put to bed the current issue---what if anything should be
put into a 2.3 release---without wrestling with long-term questions.
I *think* that a lot of the objections you raise have to do with
offering new functionality. So let's consider winnowing the "new
functionality" parts of my proposed release. Looking over the stuff
I've put in trunk
(http://people.csail.mit.edu/karger/Exhibit/alpha.html) it would seem
that the following represent changes that do *not* offer not
functionality so won't raise problems being released
* rewrote xml, html, and tsv/csv importer (all have been there for years)
* map extension to use gmaps v3, canvas
* stable sorting in tables
* upgrade jquery to 1.7
* simileajax modified to use simile-widgets.org
* bug fixes
Then there are changes that clearly offer new functionality, so should
not be in the release:
* logging. it will be a nuisance to remove all the logging calls, but
we can remove the parameter test that turns them on
* data editing. this is a standalone extension, we can host elsewhere
Then there is a grey area. I hope these can be included in the release
as argued below, essentially because they are *minor*
* label property optional. this is a trivial change (create a label if
missing) that fixes an incredibly common inexplicable and frustrating
failure for novices trying to create exhibits.
* inline data view the <link rel=exhibit/data href="#data"> tag. This
is inarguably consistent with the semantics of the link tag, and fixes
another one of the most common complaints about exhibit (not indexable)
* inline data in body tags with ex:role="data" attribute. Yes. this is
a new feature. But it's very convenient (kind of necessary) for people
who cannot access the head, and I personally would like to release it
here as a way to promise it for E3
* two new example exhibits that demonstrate the data import methods.
While certainly new, they aren't part of the code at all, just html
documents, but are convenient for people learning about or testing the tool.
I'll return to the longer-range questions in a separate email when I'm
past some deadlines.
Stefano Mazzocchi
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 Mazzocchi
wrote:
> 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.
involvement, meaning that I spent more effort helping the project in
various maintenance and management activities than in writing code
directly... it is not meant to relate with DavidH's or anybody else's
involvement..... apologies for the unfortunate phrasing.
David Karger
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.
Stefano Mazzocchi
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.
Stefano.
David Karger
To recap, I posted (at http://trunk.simile-widgets.org/) a proposed release of exhibit 2.3 with various bug fixes and feature additions. Concerns were raised that it was inappropriate to add features as this would make it harder for e3 to achieve feature parity/compatibility. I accepted this argument and formulated a proposal to exclude the egregious feature additions from the release while including those bug fixes I considered important. I've quoted that specific proposal below.
The discussion then branched into the broader topic of how to manage the commit process, with stefano helpfully posting the proposed change for review at http://codereview.appspot.com/5673046/ . But nobody has contributed to that review, and several months ago the discussion ground to a halt and nothing has happened since. I consider this a bad outcome.
I would like to bolster my revised release proposal below with the argument that it is relatively low stakes. Surely the developer community has migrated by now to exhibit 3. They should have little concern about these compatible changes to e2, and none at all about general commitment process since no further development will happen on e2. My primary concern is for the *users* of e2 who will benefit from these bug fixes (as well as a reduced dependence on the unreliable painter service).
So, can anyone who cares weigh in? If nobody does, I guess that's a sign that I'm free to make the decision on my own....
The specific proposal, quoting from my february 9 email:
You started winnowing; I will continue. This discussion was triggered at, as you say, "this particular, odd moment in time". It has broadened to cover much philosophy germane to long-term planning of our commit/release process. But I think it will simplify to split consideration of the present "odd moment" from the future planning. Perhaps we can put to bed the current issue---what if anything should be put into a 2.3 release---without wrestling with long-term questions.
I *think* that a lot of the objections you raise have to do with offering new functionality. So let's consider winnowing the "new functionality" parts of my proposed release. Looking over the stuff I've put in trunk (http://people.csail.mit.edu/karger/Exhibit/alpha.html) it would seem that the following represent changes that do *not* offer not functionality so won't raise problems being released
* rewrote xml, html, and tsv/csv importer (all have been there for years)
* map extension to use gmaps v3, canvas
* stable sorting in tables
* upgrade jquery to 1.7
* simileajax modified to use simile-widgets.org
* bug fixes
Then there are changes that clearly offer new functionality, so should not be in the release:
* logging. it will be a nuisance to remove all the logging calls, but we can remove the parameter test that turns them on
* data editing. this is a standalone extension, we can host elsewhere
Then there is a grey area. I hope these can be included in the release as argued below, essentially because they are *minor*
* label property optional. this is a trivial change (create a label if missing) that fixes an incredibly common inexplicable and frustrating failure for novices trying to create exhibits.
* inline data view the <link rel=exhibit/data href="#data"> tag. This is inarguably consistent with the semantics of the link tag, and fixes another one of the most common complaints about exhibit (not indexable)
* inline data in body tags with ex:role="data" attribute. Yes. this is a new feature. But it's very convenient (kind of necessary) for people who cannot access the head, and I personally would like to release it here as a way to promise it for E3
* two new example exhibits that demonstrate the data import methods. While certainly new, they aren't part of the code at all, just html documents, but are convenient for people learning about or testing the tool.
Ryan Lee
> This discussion thread has been silent since March, and I would really
> like to bring it to some resolution.
>
> To recap, I posted (at http://trunk.simile-widgets.org/) a proposed
> release of exhibit 2.3 with various bug fixes and feature additions.
> Concerns were raised that it was inappropriate to add features as this
> would make it harder for e3 to achieve feature parity/compatibility. I
> accepted this argument and formulated a proposal to exclude the
> egregious feature additions from the release while including those bug
> fixes I considered important. I've quoted that specific proposal below.
>
> The discussion then branched into the broader topic of how to manage the
> commit process, with stefano helpfully posting the proposed change for
> review at http://codereview.appspot.com/5673046/ . But nobody has
> contributed to that review, and several months ago the discussion ground
> to a halt and nothing has happened since. I consider this a bad outcome.
the cc list in the middle of an ongoing conversation. It seemed to me
you switched pursuing this topic to an entirely different list; are you
sure you reached the appropriate audience? It doesn't seem as helpful
to your goals to start a discussion here, then propose its resolution
elsewhere.
> I would like to bolster my revised release proposal below with the
> argument that it is relatively low stakes. Surely the developer
> community has migrated by now to exhibit 3. They should have little
> concern about these compatible changes to e2, and none at all about
> general commitment process since no further development will happen on
> e2. My primary concern is for the *users* of e2 who will benefit from
> these bug fixes (as well as a reduced dependence on the unreliable
> painter service).
> So, can anyone who cares weigh in? If nobody does, I guess that's a
> sign that I'm free to make the decision on my own....
community endorsement to resolve this however you want on your own. It
seems rather the opposite.
All I've heard here is that time has passed with no further community
input, which leaves me where we began. I'd be quite happy to see a
2.2.1 bugfix-only release to meet the needs of current Exhibit 2 users;
I think it's important for that class of users to know they're being
watched out for.
David Karger
On 7/7/2012 2:01 AM, Ryan Lee wrote:
> On 2012-07-03 13:02 , David Karger wrote:
>> This discussion thread has been silent since March, and I would really
>> like to bring it to some resolution.
>>
>> To recap, I posted (at http://trunk.simile-widgets.org/) a proposed
>> release of exhibit 2.3 with various bug fixes and feature additions.
>> Concerns were raised that it was inappropriate to add features as this
>> would make it harder for e3 to achieve feature parity/compatibility. I
>> accepted this argument and formulated a proposal to exclude the
>> egregious feature additions from the release while including those bug
>> fixes I considered important. I've quoted that specific proposal below.
>>
>> The discussion then branched into the broader topic of how to manage the
>> commit process, with stefano helpfully posting the proposed change for
>> review at http://codereview.appspot.com/5673046/ . But nobody has
>> contributed to that review, and several months ago the discussion ground
>> to a halt and nothing has happened since. I consider this a bad outcome.
> From what I recall, I ended up hearing about this when I was added to
> the cc list in the middle of an ongoing conversation. It seemed to me
> you switched pursuing this topic to an entirely different list; are you
> sure you reached the appropriate audience? It doesn't seem as helpful
> to your goals to start a discussion here, then propose its resolution
> elsewhere.
originally posted on this same mailing list on february 9.
>> So, can anyone who cares weigh in? If nobody does, I guess that's a
>> sign that I'm free to make the decision on my own....
> I don't see how not receiving any participation could be perceived as a
> community endorsement to resolve this however you want on your own. It
> seems rather the opposite.
>
> All I've heard here is that time has passed with no further community
> input, which leaves me where we began.
hand, I've certainly seen "community input" in the form of complaints
that the painter is down, or something doesn't work in IE8, or that an
xml importer is desired, etc. It was that input that drove much of
what I wrote.
> 2.2.1 bugfix-only release to meet the needs of current Exhibit 2 users;
> I think it's important for that class of users to know they're being
> watched out for.
care if it's called 2.3 or 2.2.1. The point of my proposal was to try
to define what constitutes bug fixes. Thus my proposal was to push out
the changes that
1. replace the buggy html importer with one that actually works
2. address the bug that map-view stops working when painter is down, by
switching to canvas (granted, if I had predicted the demand for
bugfix-only I wouldn't have switched to gmaps v3 at the same time, but I
still would like to push out the fix).
3. fix the bug of unstable table sorting
4. fix the bug of referring to simile.mit.edu (which is unreliable) in
simileAjax
5. "fix" bugs in old jquery by replacing with new jquery
Then comes the grey area. Is it a bug for exhibit to fail if someone
forgets a label? I think so, and want to include the feature that
generates labels for items without them. Adding a csv importer isn't a
bug fix, but has been a requested feature. It is entirely independent
of other code, so would it matter? Ditto for inline import of data.
Ryan Lee
to review. I'm well aware of the mail you've sent to this
list; I find it an odd choice that when you were actually pursuing a
concrete path forward, it was announced to a different one.
>>> So, can anyone who cares weigh in? If nobody does, I guess that's a
>>> sign that I'm free to make the decision on my own....
>> I don't see how not receiving any participation could be perceived as a
>> community endorsement to resolve this however you want on your own. It
>> seems rather the opposite.
>> All I've heard here is that time has passed with no further community
>> input, which leaves me where we began.
> No further community input on the proposed release, right.
point about the code review announcement is that there may be other
reasons you haven't heard anything further on it.
> On the other
> hand, I've certainly seen "community input" in the form of complaints
> that the painter is down, or something doesn't work in IE8, or that an
> xml importer is desired, etc. It was that input that drove much of
> what I wrote.
it's not the topic at hand. Great intentions do not set the boundaries
for releases.
>> I'd be quite happy to see a
>> 2.2.1 bugfix-only release to meet the needs of current Exhibit 2 users;
>> I think it's important for that class of users to know they're being
>> watched out for.
> Yes, I have acquiesced to the objective of a bugfix release. I don't
> care if it's called 2.3 or 2.2.1. The point of my proposal was to try
> to define what constitutes bug fixes.
As noted above, I think your initial steps in this direction were
insufficient. Make a proper announcement of the review to this list,
point to the URL, let's agree upon a reasonable deadline. I'll commit
to taking some time to enter into the process. I hope others will as well.
David Karger
(or 2.2.1) release.
I've listed the proposed major changes previously.
Stefano Mazzochi was kind enough to set up a code review site:
http://codereview.appspot.com/5673046/
I request anyone with an interest in the topic to visit and comment.
This list has gotten busier recently with a bunch of relatively
low-level code discussion. If you're a non-programmer who is finding
this a burden, please let us know.
In particular, out of respect for the many non-programmers on the list,
who I doubt will be interested in coding nitpicks, I'd like to suggest
that email discussion of the code (if any) be directed to the
simile-widgets-dev mailing list.
Jeff Roehl
From: David Karger <kar...@mit.edu>
To: simile-...@googlegroups.com
Cc: Ryan Lee <rya...@zepheira.com>
Sent: Tuesday, July 10, 2012 10:01 AM
Subject: Re: [Simile-Widgets] Re: alpha release of exhibit 2.3
--
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-widgets+unsub...@googlegroups.com.
Ryan Lee
Please start a new thread if you have a new topic to discuss. This has
no relation to the message you've replied to. Thanks.
On 2012-07-10 15:23 , Jeff Roehl wrote:
> Hey, David!
>
> Is there a way to dictate the size of a single picture in the timeline? If not, is there a way to dictate a single uniform size for all icons in a single band without affecting the icon size in other bands?
>
> Sort of like what you can do in HTML, like this:
>
> <img src="planets.gif" width="145" height="126" />
>
>
> What I want to do is include a bunch of pictures in a timeline band that are all of different sizes.
>
> I would like to display them all as 40 by 40 pixel squares. Basically big icons.
>
> I have tried:
>
> theme.event.instant.iconWidth = 20;
> theme.event.instant.iconHeight = 20;
>
> In the theme, but that only seems to change how close surrounding text is to the icons, sort of like a margin setting. It doesn't actually change the size of the graphics.
>
> I tried the following in the XML timeline data (maxheight and maxwidth):
>
> <event
> start="Dec 25 1776 00:00:00 GMT"
> image="http://upload.wikimedia.org/wikipedia/commons/thumb/9/95/800px.jpg"