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

Reply via email to