On Mon, Jul 13, 2009 at 9:42 AM, Timothy Perrett <[email protected]>wrote:
> > Hey David, > > Yeah - before Marius replied, I was not aware the same method existed > on LiftSession; my bad. > > Anywho... what are you thinking on Marius' suggestion about using > localSetup in a comet actor? I think that should negate the issues > with the comet actor being placed on the page dynamically.... also, > perhaps I could have an attribute that one could specify to override > using the main domain (I believe this is what facebook do, use > multiple domains that is). > > Would I be right in saying that the 2 connection issue only becomes a > problem if there is another comet actor in play (3rd party to my > widget and implemented by the user elsewhere)... do you think > integrating something like jquery upload progress would be better / > more simple? The Actor issue is larger than the 2 actors problem. If the Actor is doing the long poll and another component on the page tries to do Ajax, you move into trouble-land. > > > Thoughts? > > Cheers, Tim > > On Jul 13, 5:27 pm, David Pollak <[email protected]> > wrote: > > Tim, > > > > I would avoid any and all globals. I'd strongly suggest finding a way to > do > > things with sessions. > > > > There's no way to push an ad hoc CometActor to the browser. CometActors > > must be on the page at full page-load time. They can be hidden and > dormant, > > but they must be on the page. I'd opt for a timed poll rather than comet > > push. A 1 second or 3 second resolution on the upload widget update > seems > > very reasonable to me. > > > > I suspect that you'll run into a nasty problem with the 2 connection > limit > > that browsers have. You've got 1 connection for the upload... you have > to > > carefully manage the second connection. > > > > Thanks, > > > > David > > > > On Sun, Jul 12, 2009 at 11:57 AM, Timothy Perrett > > <[email protected]>wrote: > > > > > > > > > > > > > > > > > Hey guys, > > > > > Implementing this upload progress widget with comet, I just wanted a > > > quick sense check about how to organize things. > > > > > As the CometActor for a particular session will be instantiated adhoc, > > > and the LiftRules.progessListener is global, my current thinking is to > > > register a given comet actor with a singleton manager actor upon its > > > instantiation. Giving a progressListener something like: > > > > > LiftRules.progessListener = (pBytesRead, pContentLength, pItems) => { > > > UploadProgressManager ! StatusUpdate( > > > S.session.map(_.uniqueId).openOr("default"), > > > pBytesRead, pContentLength, pItems) > > > } > > > > > The idea being that when comet actors register with the manager actor > > > they give there sessionId and then I can ensure that only upload > > > progress for the current session goes to a given user (and user B > > > doesnt get user A's upload progress). > > > > > However, I cant help but feel this is a little messy? Thoughts? > > > > > Cheers, Tim > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
