Re: Server-Side Events encoded in JSON

2011-04-29 Thread Benjamin Goering
All of this functionality can be built upon the current spec, but
constraining the spec to support this convenience precludes other uses.

On Wed, Apr 27, 2011 at 11:42 PM, Brett Zamir bret...@gmail.com wrote:

 user to parse the response text, why not simply allow each event to be a
 JSON-encoded object of some kind (boolean, number, string, array, object).
 Then the event.data could be an object which was already conveniently
 accessible to JavaScript consumers. Presumably server-side libraries would
 handle the work of doing the encoding, but the average client-side consumer
 should, in my opinion, not need to be concerned with implementation details,
 except to become familiar with the specific JSON response types being sent
 by the server-side code/library.

 Although this would add encoding responsibilities to the server and
 decoding responsibilities to the browser, I think it ought to avoid the need
 for the client code to be concerned with ugly implementation details such as
 the need to parse strings.

 A convention might also be used in the stream (e.g., error:  followed by
 a JSON object) to trigger errors, allowing the normal responses to be simple
 strings or the like, while offering a means to distinguish them from error
 messages sent by the server (e.g., to indicate that a data source was no
 longer available). The event object could add an error property which
 could be checked (or, if types were allowed as per my previous post, it
 could set the event type to the reserved string error).

 Brett






-- 
Benjamin Goering
Hacker, Goofy Guy
Livefyre Inc.
+1(785)224-0136


Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Benjamin Goering
Glad to see this. I was 'checking in' on the professional practicalities of
custom elements earlier this week, and was pretty bummed when I couldn't
use XHTML5 namespaces for my employer's organization.

I build widgets all day. They run in inhospitable that websites I'm not in
control of. They have so many globals I just can't even. I get planning,
execution, and/or distribution friction when the standards prevent be from
creating a truly universal web component that will work in all those
environments.

To Tab's point, I don't think that will prevent a 90%-sufficient solution,
or one that is 99%-sufficient for some subset of the potential market.
But I do agree with Kurt that eventually it seems like 'the right way'.

It seems valuable today to at least standardize and have a spec for XHTML5
Custom Elements (e.g. my-vendor:jquery/). 1% of sites will actually use
these in a way that fully validates against XHTML5. But at least web
authors and developers will be using the web instead of Contrived
JavaScript Embeds.

With a vote of confidence (or better yet spec) on the consistency of XHTML5
Custom Elements, I see no reason why I couldn't in the interim use this,
and sleep at night knowing it will eventually be the way the web actually
works:

html xmlns:my-vendor=https://html.my-vendor.com/elements;
span is=my-vendor:jquery /
/html

or

div xmlns=https://html.my-vendor.com/elements;
span is=jquery@~2.9 /
span is=react@^1.3 /
/div

One of the cool things about this is: Let's say in that last example I need
to switch vendors or change where in the cloud my elements come from (e.g.
QA, Staging, Production). All I need to change is the xmlns URL in that one
attribute.

Critiques?

--
Benjamin Goering - @bengo
Platform @Livefyre Labs

On Wed, Feb 4, 2015 at 5:15 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@gmail.com wrote:
  I predict that sometime around 2025, we will end up redefining namespaces
  because the number of jQuery-like components have ballooned into the
  millions, the web has descended once again into a sea of
 interoperability,
  and registries will, once again, have proven to be a bottleneck, as they
  have EVERY SINGLE TIME they have been implemented.

 Yes, real namespacing does eventually prove necessary as the
 population grows.  That's fine.  It's something that can be added
 organically as necessary; letting everything live in the null
 namespace first doesn't harm future namespacing efforts.

  Of course, they won't be called namespaces, and they'll probably use a
 dash
  instead of a colon , and they definitely won't be XML based because
 everyone
  knows that XML is EVIL ... (sigh) !

 There are more namespacing solutions in heaven and earth, Horatio,
 than are dreamt of in your XML.  Most of them don't commit the same
 mistakes that XML namespaces did.

 ~TJ