A few thoughts: 1) You will have better luck, I think, building the library first, distributing it, and showing there is a need. Then you'll have momentum in your favor. One way to help get it out there is scripteka.com.
2) It feels a little like you're asking someone else to do the programming work for you. Maybe you're not, but it comes across that way. Dive in and help. 3) I still don't see a use case for this that isn't a) better solved through other technology, or b) can't be solved by polling (e.g. Ajax.PeriodicalUpdater). It seems to me that most of the Comet methods described in the Wikipedia page (thanks for the link) require a similar level of browser/network/server resources as polling, with less cross-browser compatibility. Even if the above issues are resolved, just because it's a good idea doesn't mean it belongs in the core. The core is (as I interpret it) is something _everybody_ needs. Specialized uses, like script.aculo.us' superb effects library are properly separated. TAG On Nov 30, 2009, at 8:56 AM, David Kaufman wrote: > Hi Sebastien, > > In case you missed it there at the end, Allen was referring you to a > javascript programming pattern you might have overlooked in your research: > > Comet: http://en.wikipedia.org/wiki/Comet_%28programming%29 > > I'd argue that is does belong in any discussion of the future of > prototype, precisely *because* "there is no standard way to interact > with these server side applications". > > IMO prototype is uniquely positioned to standardize such a way, and > hopefully would wrap up the interface nicely in just the right way for > developer ease of use, while hiding (as it has in the past) the ugly > browser-dependent plumbing underneath so that we don't have to care > that, for instance, a) classic comet always-connected multi-part > messaging works on Gecko browsers but b) you have to fall back to a > stream of long-polling script tags in a hidden iframe on webkit, and of > course c) HTML5 will button all this up in a new, efficient standards > compliant way for all browsers. > > I'd personally prefer all that ugliness be hidden from me so I can write > 3-line comet calls now that will Just Work off into the unknown future, > and its history of delivering those types of future-proof API's is what > I've always loves about prototype! > > -dave > > Allen Madsen wrote: >> IMO, this does not belong in core. Firstly, the technology to enable >> push resides largely on the server side. Secondly, there is no >> standard way to interact with these server side applications, which >> suggests these would be better as plugins to support the best comet >> implementation for your project. >> >> Allen Madsen >> http://www.allenmadsen.com >> >> >> >> Sebastien <sebastien.and...@gmail.com> wrote: >>> Hi everybody. >>> >>> I'm writing this to propose you a great improvement for the >>> framework : the server push [...] It's in fact a kind of data streaming. >>> >>> I searched onto the web a way to do that. I found APE [and] DWR [...] >>> The problem of APE is [snipped, and] The problem of DWR is [also snipped] -- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
