Perhaps I misunderstood. Although I'm not going to support all the older trial proposals of the websocket protocol - will just start with the actual accepted standard - certainly it's important to support a wider range of protocols one way or another. I've already started work on adding an HTTP server so that an additional server will not be required to serve web pages and those can drag in a lot of stuff. XML etc. isn't going to disappear because of websockets and even though it's possible to use websockets instead of AJAX, one might as well use AJAX in request-response applications, and there's no reason to rebuild all the AJAX mechanisms that are still useful. ... for example. Also, aside from providing a non-browser websocket client framework, HLL supports other basic and higher level "intelligent" standard communications protocols. This results in an "open design" for interaction with other systems and applications.
________________________________ Från: Doc <drc...@drclue.net> Till: svg-developers@yahoogroups.com Skickat: måndag, 3 oktober 2011 1:26 Ämne: Re: SV: SV: SV: [svg-developers] Websocket Discussion Group Yes, earlier versions of the HyBi (websocket) protocol had security problems (long since addressed) , and I would discourage enabling of those versions in *public facing applications* ,especially prior to the advent of data masking, unless one fully understands and accounts for the issues with those early protocols. Of course our goal in supporting older and non websocket protocols in AsterClick has less to do with browsers and more to do with connections with back end infrastructure, inter server communications and those developers trying to make simple day to day connections with other infrastructure where neither the developer nor the other infrastructure knows anything about HyBi. We started the development of our infrastructure nearly two years back when the websocket protocol was still largely just an idea, fully knowing that it was bleeding edge *ALPHA campaign* development and we would probably get t-boned once or twice until the wire portion of the protocol stabilized. In reality, things have turned out far, far ,far better than we expected and really only a few items ever caused us to groan in all that time 1.) Handshakes - The little HTTP dance the server and client go through when "upgrading" from HTTP to HyBi or closing the connection. 2.) Framing - The unseen gift wrapping each message between the client and server is contained in. 3.) Funding - The donations that keep the computers both powered and connected and the AsterClick team fed. *Handshakes* : Almost any protocol involving ongoing communications will have some sort of opening dance, where the server and client sort out the details of a connection. We actually keep the opening handshakes in separate classes derived from a common base so that if several versions of a protocol share the same handshake logic in spec they can do so in code. This also means that for some back end applications we can use custom or abbreviated hand shakes or dispense with them entirely If I have a typical PHP,JAVA,C++ or other developer working on perhaps injecting a Jabber XMPP , RSS or other source into AsterClick's XML stream , I need not waste the time , money or system resources in having that developer learn, create or duplicate (HyBi) functionality simply to merge some back end data or function. *Framing:* Framing was a real head banger when it went from simply chr(0).utf8(message).chr(255) to being the rather involved animal it is. Of course it's been ~ten versions and many months since that transition with no real problems since , save knowing which version was going to be in play after any particular upgrade to the developers version of the Chrome browser we develop against. This problem became largely moot as of version ~8, when the websocket (HyBi) protocol added version negotiation in the opening handshake between the server and client, so it matters not one bit what happens in version 18,19,20 etc. as we simply negotiate a protocol version common to both the server and client. For those versions predating the negotiation feature, header sniffing and similar tactics are used. With the current focus in the protocol development having nothing to do with the basic wire protocol but rather having moved onto dynamically extending the protocol with custom features we see no issues in going forward with mainstream development which is why in our particular project we are transitioning to the *BETA campaign* which is of course the last stop before a production version. *Funding: *As an open source project AsterClick relies on donations to pay for lights,equipment,food and the like and I would say of all the challenges this project has faced , keeping the lights on has been the most difficult. I'm not going to put the beg on in this message , although I will mention that the email address on this message does accept PayPal. In *our point of view* If someone wants to create a back end AsterClick client to to tie in some pre-existing functionality such as injecting external XML (Jabber XMPP ,RSS data ) or perhaps tie in their existing user authentication system (A popular request), or whatever else, were not going to impose 4300+ lines of specification as the price of admission. A lot of people when hearing *WebSockets* have the term firmly tied to web browsers, but this is simply because thats typically the context in which WebSockets are discussed. WebSockets do not need Web Servers,Browsers ,HTML, Javascript or any of that to back up their value. Indeed one of the common use cases for AsterClick involves none of those commonly seen companions of the WebSockets discussion. If after appraising the situation , it's more reasonable and cost effective to connect an existing back end process as a websocket 0.0 client I'm going to make sure that option is there. If somebody wants to use an older version in a public facing application and has both recognized and accounted for the security issues via other means , there too , I'm not going to stop them. I most certainly will WARN them , but much like the shell command "rm -f -r /" (don't type that unless your Bank of America ), I'm not going to ban it's existence. In the end though , I think the differences in our views have more to do with our differing vantage points and goals than anything else. --Doc On 10/02/2011 11:02 AM, Roger F. Gay wrote: > But up to "version 8" there were security problems. What infrastructure? The > standard isn't even final yet. I think anyone who was building their one > infrastructure in advance of the standard would be aware that the websocket > standard is not final and the need to update to the final standard. I don't > mind a bit not supporting all the draft proposals. You'll notice also that > the older ones are marked "obsolete." That's just the way I'll treat them. > Especially since, at this point, the audience is made up of web-page builders > and developers. As you know, quite a bit is done by trial and error. I mean - > documentation only takes you so far. All development is that way. Being > agnostic about the standard would open them up to errant coding. > [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ ----- To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: svg-developers-dig...@yahoogroups.com svg-developers-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: svg-developers-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
