You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Nick Lothian <nl...@educationau.edu.au> on 2008/01/07 04:50:24 UTC
org.apache.shindig.gadgets package and extension points
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
nlothian@apache.org
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.
Re: Non java based containers
Posted by Kevin Brown <et...@google.com>.
Unfortunately, this is just the sad state of software engineering today.
What can you do? :)
There was someone working on a ruby implementation outside of shindig. We
would absolutely love to have more language implementations, though. The
only reason why we only have Java and PHP right now is because they are what
made sense for our own respective infrastructures (java in the google case,
php in the ning case). Adding python and ruby to the mix will probably
satisfy the bulk of the potential consumers of the code.
Since parts of the spec don't have formal public documentation yet
(especially the xml parsing), the best starting point for someone interested
in doing another language port would probably be to check out the java
implementation (which is currently the most feature complete) and use that
as a point of reference. Hopefully the people working on spec documentation
will have that available for us relatively soon.
~Kevin
On Jan 8, 2008 10:09 AM, Santiago Gala <sa...@gmail.com> wrote:
>
> El lun, 07-01-2008 a las 14:20 +1030, Nick Lothian escribió:
> > 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.
> >
>
> After reading "Execution in the Kingdom of Nouns", by Steven Yegge
> (
> http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html), I can't avoid getting anxious about expressions like
>
> org.apache.shindig.gadgets.BasicRemoteContentFetcher.fetch() :)
>
> Speaking about that, is there people interested in developing container
> implementations in languages with verbs? Say Python or Ruby, others?.
> I'm not sure about different people's plans around here.
>
> For the moment I'm aware of Brian's PHP seed code and the container
> coming from Google. Any other plans that can be made public?
>
> Regards
> Santiago
>
>
>
Non java based containers
Posted by Santiago Gala <sa...@gmail.com>.
El lun, 07-01-2008 a las 14:20 +1030, Nick Lothian escribió:
> 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.
>
After reading "Execution in the Kingdom of Nouns", by Steven Yegge
( http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html ), I can't avoid getting anxious about expressions like
org.apache.shindig.gadgets.BasicRemoteContentFetcher.fetch() :)
Speaking about that, is there people interested in developing container
implementations in languages with verbs? Say Python or Ruby, others?.
I'm not sure about different people's plans around here.
For the moment I'm aware of Brian's PHP seed code and the container
coming from Google. Any other plans that can be made public?
Regards
Santiago
Re: org.apache.shindig.gadgets package and extension points
Posted by Kevin Brown <et...@google.com>.
On Jan 6, 2008 10:16 PM, Nick Lothian <nl...@educationau.edu.au> 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:etnu@google.com]
> Sent: Monday, 7 January 2008 4:16 PM
> To: shindig-dev@incubator.apache.org
> 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 <nl...@educationau.edu.au> 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
> > nlothian@apache.org
> >
> > 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.
>
RE: org.apache.shindig.gadgets package and extension points
Posted by Nick Lothian <nl...@educationau.edu.au>.
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:etnu@google.com]
Sent: Monday, 7 January 2008 4:16 PM
To: shindig-dev@incubator.apache.org
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 <nl...@educationau.edu.au> 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
> nlothian@apache.org
>
> 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.
Re: org.apache.shindig.gadgets package and extension points
Posted by Kevin Brown <et...@google.com>.
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 <nl...@educationau.edu.au> 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
> nlothian@apache.org
>
> 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.
>