I haven't looked at tapestry-cometd as I want to come up with a fresh, unhindered approach. Or perhaps we should just look to adopt the code into tapestry-core?
On Mon, Apr 8, 2013 at 8:23 PM, Taha Hafeez Siddiqi < tawus.tapes...@gmail.com> wrote: > Agree with Bob as far as chat applications are concerned. > > I recently worked on a cometd-tapestry chat application and I was doing a > lot more in javascript than in tapestry although I did integrate > tapestry-security and tapestry-ioc which made the job a lot easier. > > BTW, there is already a tapestry-cometd module by Lance. > > regards > Taha > > On 09-Apr-2013, at 7:13 AM, Bob Harner <bobhar...@gmail.com> wrote: > > > Doesn't the switch to ETags for modules make for much chattier web apps, > > with lots more "conditional GET" requests for JS modules coming in after > > every page request? > > > > In any case, good riddance to the application version numbers. > > > > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hls...@gmail.com> > wrote: > > > >> With the ETag support in place, there's no longer any need for the > module > >> asset URLs to have a checksum or version number; they are no longer > given a > >> far-future expires header. > >> > >> URLs (by default) look like "/modules/t5/core/dom.js" (where the module > >> name is t5/core/dom). > >> > >> The application version number is no longer used in any URLs; it now > exists > >> just for documentation purposes (its written to the console at startup > and > >> in the exception report). This is good news, because you could screw > >> yourself by deploying your application and NOT changing the version > number > >> (in 5.3.6). > >> > >> Very happy about this ... next up, thoughts on cometd/server-push > support? > >> > >> > >> > >> On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hls...@gmail.com > >>> wrote: > >> > >>> > >>> > >>> On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gu...@gmail.com > >>> wrote: > >>> > >>>> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hls...@gmail.com > >>>>> wrote: > >>>> > >>>>> I've been working, a few hours a week, on getting per-asset checksums > >>>> into > >>>>> URLs. > >>>>> > >>>>> Some parts of this have been a challenge to accomplish without > >>>> completely > >>>>> breaking the Asset interface and a bunch of public services. > >>>>> > >>>>> For ordinary assets, it's pretty easy ... but for aggregated > >> JavaScript > >>>>> libraries its been a pain that's affected a bunch of stuff. > >>>>> > >>>>> CSS files are now rewritten, since relative URLs will be broken by > the > >>>>> addition of the checksum. I have a first (but not final) pass at > this, > >>>> > >>>> where url() patterns in the CSS are converted into complete paths. > This > >>>>> also opens the door to CSS aggregation as well as JavaScript > >>>> aggregation. > >>>>> > >>>>> > >>>> It depends on where you put the checksum. > >>>> If you put it as a GET parameter - then no relative URLs will be > broken. > >>>> > >>>> Have you read my blog post about Tapestry5 checksums in assets? > >>>> > >>>> > >> > http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html > >>> > >>> > >>> I'll read this shortly. I've generally assumed that URLs with query > >>> parameters are less likely to be cached in the browser, or served > >> properly > >>> by intermediate (reverse proxy) servers, but I haven't done the > research. > >>> > >>> > >>>> > >>>> > >>>>> I still don't have a great solution for JavaScript modules; > >>>> RequireJS/AMD > >>>>> expect that there's a common root folder name (such as > >>>> "/assets/modules/"), > >>>>> and module "a/b" is simply "*root*/a/b.js". For individual modules, > >> you > >>>> can > >>>>> write your own overrides. In fact, Tapestry has to strip off the > >> ".js' > >>>>> part (which is hard-wired by RequireJS) because the actual > server-side > >>>>> resource could be CoffeeScript or some other language that compiles > to > >>>>> JavaScript. > >>>>> > >>>>> Short of iterating all server-side module files and writing a > >> RequireJS > >>>>> config for each one (mapping each name to a URL with an embedded > >>>> checksum), > >>>>> there isn't a great solution. Alternately, something could iterate > >> all > >>>> the > >>>>> server-side modules and built a composite checksum, but there are at > >>>> least > >>>>> a couple of virtual modules generated at runtime (and locale specific > >>>> for > >>>>> extra kicks). > >>>>> > >>>>> Modules may have to stay on the 5.3 approach: using the application > >>>> version > >>>>> number for everything. > >>>>> > >>>>> Finding the sweet spot where assets of all kinds (CSS, JavaScript > >>>>> libraries, JavaScript modules, etc.) can be changed freely and the > >> URLs > >>>>> automatically reflect the actual content (that is, include a checksum > >> of > >>>>> that content) for ideal client-side caching ... may simply be out of > >>>> reach. > >>>>> > >>>>> Perhaps for modules we should use an alternate approach based on > >> ETags ( > >>>>> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there > >> would > >>>>> not > >>>>> need to be any version number of checksum in a module URL, but > clients > >>>>> would request the module content more often (and based on ETag, would > >>>> often > >>>>> get a 304 Not Modified). I would prefer to see a URL that changes > >> when > >>>> the > >>>>> content changes (which prevents the request entirely). > >>>>> > >>>>> -- > >>>>> Howard M. Lewis Ship > >>>>> > >>>>> Creator of Apache Tapestry > >>>>> > >>>>> The source for Tapestry training, mentoring and support. Contact me > to > >>>>> learn how I can get you up and productive in Tapestry fast! > >>>>> > >>>>> (971) 678-5210 > >>>>> http://howardlewisship.com > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Dmitry Gusev > >>>> > >>>> AnjLab Team > >>>> http://anjlab.com > >>>> > >>> > >>> > >>> > >>> -- > >>> Howard M. Lewis Ship > >>> > >>> Creator of Apache Tapestry > >>> > >>> The source for Tapestry training, mentoring and support. Contact me to > >>> learn how I can get you up and productive in Tapestry fast! > >>> > >>> (971) 678-5210 > >>> http://howardlewisship.com > >>> > >> > >> > >> > >> -- > >> Howard M. Lewis Ship > >> > >> Creator of Apache Tapestry > >> > >> The source for Tapestry training, mentoring and support. Contact me to > >> learn how I can get you up and productive in Tapestry fast! > >> > >> (971) 678-5210 > >> http://howardlewisship.com > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
