On 23 ÌÜúï 16:33, Luis Lavena <luislav... / gmail.com> wrote:
> On May 22, 5:53 ¨Âí¬ ÉìéáÌáúáòéäé¼éì®®®Àìáúáòéäéó®ãïí÷òïôåº
> > The binaries for JSON
> > [...] - (complex information)
>
> > In the current version of EventMachine
> > [...] - (complex information)
>
> What you consider "complex" information is needed information.

What can I say. Possibly: thank you for providing the information, I
am sure that other readers have reviewed it (or will review it).

> > May someone can tell me:
>
> > Who can provide / upload the native gems (windows binaries) of the
> > "eventmachine"?
>
> Gem authors.
[...]

ok

> > And who could provide / upload an automated fall-back to the
> > "json_pure" if "json" cannot be build locally?
>
> There is no possible fallback in that scenario, you need to code in
> your application/library/whatever you're writing this fallback.

something like (pseudocode)
try:
  require gem "json" version ...
catch:
  require gem "json_pure" version ... # fallback to json_pure, thus
gem retrieval does not abort.

> Also, if you want this attempt to be solved in each of the libraries
> you mention, patches are welcome.

I understand that "patches are welcome", as those are open source
projects.

(You really don't have to mention it every time.)

-

The "thin" / "eventmachine" issue is trivial:

 * thin should require only "eventmachine" versions which have native
gems available.

The "json" issue:

The author
 * should provide native gems, or
 * should provide "json_pure" as a pseudo-native-gem for windows (or
as a general fallback)

The "gem" issue:

The gem team should provide a mechanism for "fallbacks", in order to
ensure that cases like "json" can be resolved immediately without user
interventions (instead of aborting the gem installation sequence which
is triggered by a gem with dependencies).

Some gems are far to important, and they can mess up the user-
experience completely.

-

I have understood the issues now.

Thank you very much for your time!

.

--
http://lazaridis.com