I agree with both of you, I think it is 'too soon' to remove the IMultithreaded code. All of it is already marked deprecated and I will leave it as such as I move through cleaning up code.
-Eric PS: I'm making a best effort to make sure any larger changes being made in the trunk are communicated here on the list. If people see commits that I haven't talked about feel free to ask me about them Andrew Petro wrote: > Hi Eric, > > "Make wars, not war." > > I'm with Dan on this one. IMultithreaded has not been deprecated > <http://www.ja-sig.org/wiki/display/UPC/Proposal+to+Deprecate+IMultithreaded+Interfaces> > > long enough to be removed outright; removing it outright will > significantly inconvenience folks who coded channels in what was prior > to the realization that IMultithreaded was a bad idea, the "best > practices" recommended way. > > It seems to me that the relevant potential uPortal and JA-SIG have > started to take action on is to JSR-168-ify the most popular channels. > (This is happening at least in spirit, vis. the Email Preview Portlets > starting to move in on some of the UBC_Webmail use cases.) > CAnnouncements* would be even better formulated as a Spring > PortletMVC-implemented JSR-168 portlet > <http://www.ja-sig.org/wiki/display/UPC/CAnnouncements+2007+JHU+Dev+Meeting+Slot> > > -- in such a design it might even be possible to accommodate the > varying announcements channel needs on a single shared codebase > different configured locally, which would have significant advantage > in making progress rather than forks. > > I believe the best tactical move here is for JA-SIG to go after > JSR-168 and Spring PortletMVC in a big way, for the architecture > advantages, for the collaboration advantages. If we do that, using > the Unconference <http://www.ja-sig.org/wiki/display/JCON/Winter+2007> > and our conference and our camaraderie to grow towards that as the > go-to way to implement portal widgets for this community in a way that > the source can be most usefully shared among us, then the end of > IMultithreaded*Channel support in uPortal will be one of pull factors > rather than the push factor of an API-still-in-use being pulled out > from under. > > > However, if Springification of uPortal > <http://www.ja-sig.org/issues/browse/UP-1366> progresses to the point > where ChannelManager etc. implementation is declaratively configured, > then there may very well be room in the world for > MultithreadedChannelSupportingChannelManager vs. > SleekNoMultithreadedsChannelManager . It's probably worth more > thorough investigation before doing that heroics, but as noted in the > page pitching deprecating IMultithreaded > <http://www.ja-sig.org/wiki/display/UPC/Proposal+to+Deprecate+IMultithreaded+Interfaces>, > > review of the code suggests to me that there are performance gains to > be had by eliminating IMultithreaded *support* from the framework. > Support for the IMultithreaded*s at all, whether they're used or not, > introduces lock churn on every channel instantiation. > > One of the initiatives I've pitched > <http://www.ja-sig.org/wiki/display/JCON/summer07+uPortal+2.6+presentation> > for inclusion in the scope of uPortal 3.x is a Grand Unification and > Distribution of the Cool Widgets uPortal is Sitting On But Not > Shipping By Default. Maybe this idea's not rolling off the tongue > elegantly contributes to its lack of uptake. > > If uPortal reviews the available channels and portlets, makes them > shine, includes them by default in the uPortal distribution, such that > one gets a cool announcements experience out of the box, then there's > an opportunity to 1) Standardize on some (presumably > non-IMultithreaded, quite possibly Springified) code, thereby > increasing the future potential for deprecating that API, 2) > projectify the fringe projects, getting them up to a point where > they're cutting releases suitable for inclusion in uPortal, and 3) > raising the baseline functionality of uPortal in a way that competes > with e.g. LifeRay and helps this open source project to market itself. > > My suggestion is that uPortal "*Make wars not war*" here. (Like that > one?) Eliminating support for something people are using is hostile, > a wee bit like "making war". Going after compelling shared-source > JSR-168 portlets well-architected to meet the shared needs of higher > education ("making wars"), make these easy to adopt, make it clear in > this community how effective this is as an approach for implementing > institution-local portal widgets (the Duke presentation at JA-SIG > Denver > <http://www.ja-sig.org/wiki/display/JCON/Denver+2007+presentations> > was a good step in communicating this message) and the need to support > any IChannels at all as such [1], let alone IMultithreaded, will make > great strides towards quietly going away. > > Andrew > > [1]: I'm still not convinced this means that the framework gets rid of > IChannels. IChannels, especially if uPortal were free to aggressively > evolve them to meet new JSR-168 and JSR-286 support needs, still seem > to me to be a reasonable and affective way for the portal to implement > the layer that sits above the portlet container, the boxes and tasks > the portal needs to allocate, start, and stop when they time out. > It's proving pretty convenient that CPortletAdapter exists and can > exist alongside other JSR-168 support implementations, allowing e.g. > special handling for portlets needing CAS proxy tickets. > >> Hi Eric, >> >> I'd rather see the multithreaded code deprecated, since whatever the >> advantages of removing it, it raises the cost of migration for quite >> a few current implementors. >> >> I've written a couple of multithreaded channels for local use at >> Columbia, at least one of which is still running. If I remember >> correctly, some of the Announcements channel variants are >> IMultithreadedChannels. >> >> Dan >> >> Eric Dalquist wrote: >>> With the basic Spring re-org done the next task on the block is >>> reviewing and removing deprecated code from the framework. There is >>> a Jira issue http://www.ja-sig.org/issues/browse/UP-1832 of course >>> and you can peak at the Fisheye tab to see what has been done so far. >>> >>> One large set of files that is deprecated is everything related to >>> multithreaded channels. I would like to get opinions of people on if >>> this code should be out-right removed for a uPortal 3.0 release or >>> is it ok to remain in the codebase but be deprecated? >>> >>> Thank you, >>> -Eric >> >> > > > -- > You are currently subscribed to [email protected] as: [EMAIL > PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
