So would it make sense to move the bits people are likely to replace (BasicRemoteContentFetcher etc) from the org.apache.shindig.gadgets package to the org.apache.shindig.gadgets.http package?
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) Also, how likely is it that there'll be a non-http based version? Isn't that a touch redundant? -----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.
