On Jan 6, 2008 10:16 PM, Nick Lothian <[EMAIL PROTECTED]> wrote: > So would it make sense to move the bits people are likely to replace > (BasicRemoteContentFetcher etc) from the org.apache.shindig.gadgetspackage to > the > org.apache.shindig.gadgets.http package?
Not necessarily, because they're not http specific. We could move them back to gadgets.basic, though, but I'm not sure there's much to be gained there. > > I'd worry that currently there are no real alarm bells around things like > BasicGadgetDataCache that say "don't use this in production - you'll run out > of memory". At least with a different package name there's a hope people > will realize they need to replace it. (This is based on personal experience > - I made the mistake of including a "demo" map based cache in a reasonably > popular open source project. I regretted that until I replaced it with a > LinkedHashMap version) Fair enough. Moving these things to basic would probably help here. > > > Also, how likely is it that there'll be a non-http based version? Isn't > that a touch redundant? Very. Consider the case of sites like iGoogle that need the module's meta data (title, preferred height, any container-side features that need to be present) before they can even render the iframe. I expect that most sites will be using both the http server (to run the iframe), and the library (core stuff) to build their site. As security technology improves and we eliminate the need for iframes, the http reference implementation won't be needed at all. Different sites have different needs, of course, but I expect that most sufficiently large sites will be using core directly either exclusively or in addition to the http implementation. > > > -----Original Message----- > From: Kevin Brown [mailto:[EMAIL PROTECTED] > Sent: Monday, 7 January 2008 4:16 PM > To: [email protected] > Subject: Re: org.apache.shindig.gadgets package and extension points > > Hi Nick, > > Actually, the current structure is completely intentional. Shortly before > the commit of the code to apache, we did have a "core" and "basic" > directory > with the setup as you've proposed. What you're seeing now is simply put in > place to simplify the directory structure, because we did not want to make > things overly complicated. We could have probably left > BasicRemoteContentFetcher and BasicGadgetDataCache in the "basic" > directory, > but we decided to just stick it all together for simplicity's sake. We > never > expected that many sites would actually use BasicRemoteContentFetcher or > BasicGadgetDataCache (the latter is particularly unsuitable for production > use, given that it uses a map as a "cache"), they're just there so that > the > server can actually work "out of the box". > > The "http" directory is intended to be a reference http implementation -- > it > is assumed that many sites will not be able to use the code in there as is > (except possibly for the iframe rendering), but rather will be providing > their own implementations that meet that site's specific needs. Most large > sites already have an existing caching and content retrieval facilities, > and > being able to tie back into those is extremely important. > > The stuff in the http directory should probably be using a simpler > injection > mechanism; most contributors seem to be favoring Guice, so that's probably > what we'll be using there. This is dependent on how much use the http code > actually gets, of course. Many sites will have little use for this http > implementation given that they already have their own serving > infrastructure > set up, and will probably be using the "core" parts as a library rather > than > a stand alone server. > > ~Kevin > > On Jan 6, 2008 7:50 PM, Nick Lothian <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I've been browsing the Java Shindig code a little, and I was wondering > > what thought had been put into extension points? > > > > As a specific example, I noticed that the implementation of > > org.apache.shindig.gadgets.RemoteContentFetcher ( > > org.apache.shindig.gadgets. BasicRemoteContentFetcher) kind of lives up > to > > its name. > > > > I have no issues with that, but it appears the kind of thing that people > > might need to replace (BasicGadgetDataCache is another example of this). > > > > If it is agreed this is a reasonable goal, the would it be possible to > > separate out the org.apache.shindig.gadgets into core classes/interfaces > > and implementation classes? > > > > eg: > > > > org.apache.shindig.gadgets.core: > > > > GadgetDataCache > > GadgetFeature > > GadgetView > > GadgetSpec > > GadgetException > > RemoteContentFetcher > > > > > > org.apache.shindig.gadgets.impl > > > > BasicRemoteContentFetcher > > BasicGadgetDataCache > > etc. > > > > > > (I understand that GadgetRenderingServlet is currently hardcoded to use > > those implementation classes - I'm sure many Guicey suggestions for > fixing > > that will Spring to mind...) > > > > Regards > > Nick Lothian > > [EMAIL PROTECTED] > > > > IMPORTANT: This e-mail, including any attachments, may contain private > or > > confidential information. If you think you may not be the intended > > recipient, or if you have received this e-mail in error, please contact > the > > sender immediately and delete all copies of this e-mail. If you are not > the > > intended recipient, you must not reproduce any part of this e-mail or > > disclose its contents to any other party. This email represents the > views of > > the individual sender, which do not necessarily reflect those of > > Education.AU Limited except where the sender expressly states otherwise. > > It is your responsibility to scan this email and any files transmitted > with > > it for viruses or any other defects. Education.AU Limited will not be > > liable for any loss, damage or consequence caused directly or indirectly > by > > this email. > > > > IMPORTANT: This e-mail, including any attachments, may contain private or > confidential information. If you think you may not be the intended > recipient, or if you have received this e-mail in error, please contact the > sender immediately and delete all copies of this e-mail. If you are not the > intended recipient, you must not reproduce any part of this e-mail or > disclose its contents to any other party. This email represents the views of > the individual sender, which do not necessarily reflect those of > Education.AU Limited except where the sender expressly states otherwise. > It is your responsibility to scan this email and any files transmitted with > it for viruses or any other defects. Education.AU Limited will not be > liable for any loss, damage or consequence caused directly or indirectly by > this email. >
