You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@apache.org> on 2008/03/25 14:39:15 UTC
Can we get rid of javacript/container/ifpc.js?
I can not find any Shindig usages of the code inside of
javascript/container/ifpc.js or of ifpc_relay.html. All of the samples are
now using the rpc library.
I would like to delete these two files in order to reduce duplication inside
of our code base. Is there any reason for these files to stay around that I
am missing? Is anybody relying on them? Thanks.
- Cassie
RE: Support for ContentType.FEED in makeRequest
Posted by Dan Lester <da...@danlester.com>.
Excellent - I've just uploaded the patch if anyone wants to have a look.
Also described the way I attacked Maven, but can't be sure it's the best
advice.
Dan
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 16 April 2008 23:36
To: shindig-dev@incubator.apache.org
Subject: Re: Support for ContentType.FEED in makeRequest
You could stick a patch on the JIRA issue (
https://issues.apache.org/jira/browse/SHINDIG-60) and we could take a
look.
On Wed, Apr 16, 2008 at 3:16 PM, Dan Lester <da...@danlester.com> wrote:
>
> My version of Java Shindig can now support the FEED Content Type in
> makeRequest - i.e. returns fully parsed RSS feeds as JSON objects.
>
> I've used the eddie library to parse rss on the Java side:
> http://www.davidpashley.com/projects/eddie.html
>
> My implementation is fairly basic, and I'm not sure I have the Maven,
> JUnit, Java, and Legal (check licenses) skills to submit this in a way
> that would not make you full-time coders cry.
>
> But if anyone wants the code I've written, please feel free to ask for
> it - either to integrate into your own Shindig implementation, or for
> the main code base.
>
> It just involves an addition to ProxyHandler.java and
> features/core.io/io.js.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Dan Lester [mailto:dan@danlester.com]
> Sent: 31 March 2008 19:04
> To: shindig-dev@incubator.apache.org
> Subject: RE: Support for ContentType.FEED in makeRequest
>
>
>
> Thanks for the response - shame it can't just be taken from iGoogle!
>
> I had thought the Shindig solution would also be server-side, but for
> a temporary solution you raise a good point that a client-side library
> could do the trick, although feed parsers I've used in PHP tend to be
> large, so it would be a waste to download even when not used.
>
> Perhaps I'll see if I can work out a quick fix at some stage, but
> unfortunately can't even look at it for a while, so don't let my
> comments here prevent anyone else from also trying to build a
> solution...
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 28 March 2008 18:26
> To: shindig-dev@incubator.apache.org
> Subject: Re: Support for ContentType.FEED in makeRequest
>
>
> On Fri, Mar 28, 2008 at 5:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > I've found JIRA 60 which says "Shindig does not properly support the
> > FEED content type as defined by the gadgets spec for
> > gadgets.io.MakeRequest" and it is currently unassigned.
> >
> > I'm coming across a number of gadgets that are trying to use this
> > feature - it's certainly a lot easier than parsing an XML feed; in
> > gmodules there is server-side code to break up the actual RSS fields
> > into a JSON structure.
> >
> > Anyway, it occurred to me that this code must already exist
> > somewhere within Google... Would it be possible to at least commit
> > (or post
> > elsewhere) the basic code to do that, even if it is not yet fully
> > integrated into Shindig?
>
>
> There are many RSS & Atom parsers out there -- we've been sort of
> punting on this until we get Abdera integration (which will come in
> the next few weeks with the RESTful API project).
>
> Are you looking for a solution in javascript, or a server side
> solution? Currently igoogle (gmodules.com) uses a server side solution
> for parsing feeds, and I can definitively say that it's not something
> that can be contributed to Shindig due to fundamental architectural
> differences, having worked on igoogle myself.
>
> I think we'd definitely welcome someone contributing a solution, even
> if it's only a temporary one.
>
>
> >
> > I can't promise to be able to take the steps required to integrate
> > it with Shindig, but some other general member of the public (or me)
> > might be able to help from there, if the 'offical' coders aren't
> > able to address it. Certainly, it does not make sense to start from
> > scratch, assuming Google are still able to be generous with their
> > existing code.
> >
> > Thanks,
> >
> > Dan
> >
> >
>
>
> --
> ~Kevin
>
>
>
--
~Kevin
Re: Support for ContentType.FEED in makeRequest
Posted by Kevin Brown <et...@google.com>.
You could stick a patch on the JIRA issue (
https://issues.apache.org/jira/browse/SHINDIG-60) and we could take a look.
On Wed, Apr 16, 2008 at 3:16 PM, Dan Lester <da...@danlester.com> wrote:
>
> My version of Java Shindig can now support the FEED Content Type in
> makeRequest - i.e. returns fully parsed RSS feeds as JSON objects.
>
> I've used the eddie library to parse rss on the Java side:
> http://www.davidpashley.com/projects/eddie.html
>
> My implementation is fairly basic, and I'm not sure I have the Maven,
> JUnit, Java, and Legal (check licenses) skills to submit this in a way
> that would not make you full-time coders cry.
>
> But if anyone wants the code I've written, please feel free to ask for
> it - either to integrate into your own Shindig implementation, or for
> the main code base.
>
> It just involves an addition to ProxyHandler.java and
> features/core.io/io.js.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Dan Lester [mailto:dan@danlester.com]
> Sent: 31 March 2008 19:04
> To: shindig-dev@incubator.apache.org
> Subject: RE: Support for ContentType.FEED in makeRequest
>
>
>
> Thanks for the response - shame it can't just be taken from iGoogle!
>
> I had thought the Shindig solution would also be server-side, but for a
> temporary solution you raise a good point that a client-side library
> could do the trick, although feed parsers I've used in PHP tend to be
> large, so it would be a waste to download even when not used.
>
> Perhaps I'll see if I can work out a quick fix at some stage, but
> unfortunately can't even look at it for a while, so don't let my
> comments here prevent anyone else from also trying to build a
> solution...
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 28 March 2008 18:26
> To: shindig-dev@incubator.apache.org
> Subject: Re: Support for ContentType.FEED in makeRequest
>
>
> On Fri, Mar 28, 2008 at 5:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > I've found JIRA 60 which says "Shindig does not properly support the
> > FEED content type as defined by the gadgets spec for
> > gadgets.io.MakeRequest" and it is currently unassigned.
> >
> > I'm coming across a number of gadgets that are trying to use this
> > feature - it's certainly a lot easier than parsing an XML feed; in
> > gmodules there is server-side code to break up the actual RSS fields
> > into a JSON structure.
> >
> > Anyway, it occurred to me that this code must already exist somewhere
> > within Google... Would it be possible to at least commit (or post
> > elsewhere) the basic code to do that, even if it is not yet fully
> > integrated into Shindig?
>
>
> There are many RSS & Atom parsers out there -- we've been sort of
> punting on this until we get Abdera integration (which will come in the
> next few weeks with the RESTful API project).
>
> Are you looking for a solution in javascript, or a server side solution?
> Currently igoogle (gmodules.com) uses a server side solution for parsing
> feeds, and I can definitively say that it's not something that can be
> contributed to Shindig due to fundamental architectural differences,
> having worked on igoogle myself.
>
> I think we'd definitely welcome someone contributing a solution, even if
> it's only a temporary one.
>
>
> >
> > I can't promise to be able to take the steps required to integrate it
> > with Shindig, but some other general member of the public (or me)
> > might be able to help from there, if the 'offical' coders aren't able
> > to address it. Certainly, it does not make sense to start from
> > scratch, assuming Google are still able to be generous with their
> > existing code.
> >
> > Thanks,
> >
> > Dan
> >
> >
>
>
> --
> ~Kevin
>
>
>
--
~Kevin
RE: Support for ContentType.FEED in makeRequest
Posted by Dan Lester <da...@danlester.com>.
My version of Java Shindig can now support the FEED Content Type in
makeRequest - i.e. returns fully parsed RSS feeds as JSON objects.
I've used the eddie library to parse rss on the Java side:
http://www.davidpashley.com/projects/eddie.html
My implementation is fairly basic, and I'm not sure I have the Maven,
JUnit, Java, and Legal (check licenses) skills to submit this in a way
that would not make you full-time coders cry.
But if anyone wants the code I've written, please feel free to ask for
it - either to integrate into your own Shindig implementation, or for
the main code base.
It just involves an addition to ProxyHandler.java and
features/core.io/io.js.
Thanks,
Dan
-----Original Message-----
From: Dan Lester [mailto:dan@danlester.com]
Sent: 31 March 2008 19:04
To: shindig-dev@incubator.apache.org
Subject: RE: Support for ContentType.FEED in makeRequest
Thanks for the response - shame it can't just be taken from iGoogle!
I had thought the Shindig solution would also be server-side, but for a
temporary solution you raise a good point that a client-side library
could do the trick, although feed parsers I've used in PHP tend to be
large, so it would be a waste to download even when not used.
Perhaps I'll see if I can work out a quick fix at some stage, but
unfortunately can't even look at it for a while, so don't let my
comments here prevent anyone else from also trying to build a
solution...
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 28 March 2008 18:26
To: shindig-dev@incubator.apache.org
Subject: Re: Support for ContentType.FEED in makeRequest
On Fri, Mar 28, 2008 at 5:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> I've found JIRA 60 which says "Shindig does not properly support the
> FEED content type as defined by the gadgets spec for
> gadgets.io.MakeRequest" and it is currently unassigned.
>
> I'm coming across a number of gadgets that are trying to use this
> feature - it's certainly a lot easier than parsing an XML feed; in
> gmodules there is server-side code to break up the actual RSS fields
> into a JSON structure.
>
> Anyway, it occurred to me that this code must already exist somewhere
> within Google... Would it be possible to at least commit (or post
> elsewhere) the basic code to do that, even if it is not yet fully
> integrated into Shindig?
There are many RSS & Atom parsers out there -- we've been sort of
punting on this until we get Abdera integration (which will come in the
next few weeks with the RESTful API project).
Are you looking for a solution in javascript, or a server side solution?
Currently igoogle (gmodules.com) uses a server side solution for parsing
feeds, and I can definitively say that it's not something that can be
contributed to Shindig due to fundamental architectural differences,
having worked on igoogle myself.
I think we'd definitely welcome someone contributing a solution, even if
it's only a temporary one.
>
> I can't promise to be able to take the steps required to integrate it
> with Shindig, but some other general member of the public (or me)
> might be able to help from there, if the 'offical' coders aren't able
> to address it. Certainly, it does not make sense to start from
> scratch, assuming Google are still able to be generous with their
> existing code.
>
> Thanks,
>
> Dan
>
>
--
~Kevin
RE: Support for ContentType.FEED in makeRequest
Posted by Dan Lester <da...@danlester.com>.
Thanks for the response - shame it can't just be taken from iGoogle!
I had thought the Shindig solution would also be server-side, but for a
temporary solution you raise a good point that a client-side library
could do the trick, although feed parsers I've used in PHP tend to be
large, so it would be a waste to download even when not used.
Perhaps I'll see if I can work out a quick fix at some stage, but
unfortunately can't even look at it for a while, so don't let my
comments here prevent anyone else from also trying to build a
solution...
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 28 March 2008 18:26
To: shindig-dev@incubator.apache.org
Subject: Re: Support for ContentType.FEED in makeRequest
On Fri, Mar 28, 2008 at 5:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> I've found JIRA 60 which says "Shindig does not properly support the
> FEED content type as defined by the gadgets spec for
> gadgets.io.MakeRequest" and it is currently unassigned.
>
> I'm coming across a number of gadgets that are trying to use this
> feature - it's certainly a lot easier than parsing an XML feed; in
> gmodules there is server-side code to break up the actual RSS fields
> into a JSON structure.
>
> Anyway, it occurred to me that this code must already exist somewhere
> within Google... Would it be possible to at least commit (or post
> elsewhere) the basic code to do that, even if it is not yet fully
> integrated into Shindig?
There are many RSS & Atom parsers out there -- we've been sort of
punting on this until we get Abdera integration (which will come in the
next few weeks with the RESTful API project).
Are you looking for a solution in javascript, or a server side solution?
Currently igoogle (gmodules.com) uses a server side solution for parsing
feeds, and I can definitively say that it's not something that can be
contributed to Shindig due to fundamental architectural differences,
having worked on igoogle myself.
I think we'd definitely welcome someone contributing a solution, even if
it's only a temporary one.
>
> I can't promise to be able to take the steps required to integrate it
> with Shindig, but some other general member of the public (or me)
> might be able to help from there, if the 'offical' coders aren't able
> to address it. Certainly, it does not make sense to start from
> scratch, assuming Google are still able to be generous with their
> existing code.
>
> Thanks,
>
> Dan
>
>
--
~Kevin
Re: Support for ContentType.FEED in makeRequest
Posted by Kevin Brown <et...@google.com>.
On Fri, Mar 28, 2008 at 5:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> I've found JIRA 60 which says "Shindig does not properly support the
> FEED content type as defined by the gadgets spec for
> gadgets.io.MakeRequest" and it is currently unassigned.
>
> I'm coming across a number of gadgets that are trying to use this
> feature - it's certainly a lot easier than parsing an XML feed; in
> gmodules there is server-side code to break up the actual RSS fields
> into a JSON structure.
>
> Anyway, it occurred to me that this code must already exist somewhere
> within Google... Would it be possible to at least commit (or post
> elsewhere) the basic code to do that, even if it is not yet fully
> integrated into Shindig?
There are many RSS & Atom parsers out there -- we've been sort of punting on
this until we get Abdera integration (which will come in the next few weeks
with the RESTful API project).
Are you looking for a solution in javascript, or a server side solution?
Currently igoogle (gmodules.com) uses a server side solution for parsing
feeds, and I can definitively say that it's not something that can be
contributed to Shindig due to fundamental architectural differences, having
worked on igoogle myself.
I think we'd definitely welcome someone contributing a solution, even if
it's only a temporary one.
>
> I can't promise to be able to take the steps required to integrate it
> with Shindig, but some other general member of the public (or me) might
> be able to help from there, if the 'offical' coders aren't able to
> address it. Certainly, it does not make sense to start from scratch,
> assuming Google are still able to be generous with their existing code.
>
> Thanks,
>
> Dan
>
>
--
~Kevin
Re: Can we get rid of javacript/container/ifpc.js?
Posted by Zhen Wang <wa...@google.com>.
ifpc.js, ifpc_relay.html, and json.js are all obsolete. I've deleted
them in r643645.
On Thu, Mar 27, 2008 at 12:12 PM, Kevin Brown <et...@google.com> wrote:
> On Thu, Mar 27, 2008 at 4:45 AM, Cassie <do...@apache.org> wrote:
>
> > Alright, I'll hold tight on this a little longer. I will also pose another
> > question:
> >
> > Can we get rid of javascript/container/json.js?
> > This is another duplicate library of features/core/json.js. It also seems
> > like no one is using it.
> >
> > Please speak up if you think this needs to stick around.
> > Thanks!
>
>
> That one can definitely go as long as none of the other files are
> referencing it.
>
>
>
> >
> > - Cassie
> >
> >
> > On Tue, Mar 25, 2008 at 7:47 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > On Tue, Mar 25, 2008 at 6:39 AM, Cassie <do...@apache.org> wrote:
> > >
> > > > I can not find any Shindig usages of the code inside of
> > > > javascript/container/ifpc.js or of ifpc_relay.html. All of the samples
> > > are
> > > > now using the rpc library.
> > > >
> > > > I would like to delete these two files in order to reduce duplication
> > > > inside
> > > > of our code base. Is there any reason for these files to stay around
> > > that
> > > > I
> > > > am missing? Is anybody relying on them? Thanks.
> > >
> > >
> > > I can't think of any reason to keep them. The legacy mapping in rpc.js
> > > takes
> > > care of dealing with parent containers that are still using ifpc, so
> > > there's
> > > really no good reason for keeping it around so far as I know. I'd leave
> > it
> > > around for at least a week though -- Zhen is on vacation and I suspect
> > > he's
> > > not checking his email.
> > >
> >
>
>
>
> --
> ~Kevin
>
Re: Can we get rid of javacript/container/ifpc.js?
Posted by Kevin Brown <et...@google.com>.
On Thu, Mar 27, 2008 at 4:45 AM, Cassie <do...@apache.org> wrote:
> Alright, I'll hold tight on this a little longer. I will also pose another
> question:
>
> Can we get rid of javascript/container/json.js?
> This is another duplicate library of features/core/json.js. It also seems
> like no one is using it.
>
> Please speak up if you think this needs to stick around.
> Thanks!
That one can definitely go as long as none of the other files are
referencing it.
>
> - Cassie
>
>
> On Tue, Mar 25, 2008 at 7:47 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Tue, Mar 25, 2008 at 6:39 AM, Cassie <do...@apache.org> wrote:
> >
> > > I can not find any Shindig usages of the code inside of
> > > javascript/container/ifpc.js or of ifpc_relay.html. All of the samples
> > are
> > > now using the rpc library.
> > >
> > > I would like to delete these two files in order to reduce duplication
> > > inside
> > > of our code base. Is there any reason for these files to stay around
> > that
> > > I
> > > am missing? Is anybody relying on them? Thanks.
> >
> >
> > I can't think of any reason to keep them. The legacy mapping in rpc.js
> > takes
> > care of dealing with parent containers that are still using ifpc, so
> > there's
> > really no good reason for keeping it around so far as I know. I'd leave
> it
> > around for at least a week though -- Zhen is on vacation and I suspect
> > he's
> > not checking his email.
> >
>
--
~Kevin
Support for ContentType.FEED in makeRequest
Posted by Dan Lester <da...@danlester.com>.
I've found JIRA 60 which says "Shindig does not properly support the
FEED content type as defined by the gadgets spec for
gadgets.io.MakeRequest" and it is currently unassigned.
I'm coming across a number of gadgets that are trying to use this
feature - it's certainly a lot easier than parsing an XML feed; in
gmodules there is server-side code to break up the actual RSS fields
into a JSON structure.
Anyway, it occurred to me that this code must already exist somewhere
within Google... Would it be possible to at least commit (or post
elsewhere) the basic code to do that, even if it is not yet fully
integrated into Shindig?
I can't promise to be able to take the steps required to integrate it
with Shindig, but some other general member of the public (or me) might
be able to help from there, if the 'offical' coders aren't able to
address it. Certainly, it does not make sense to start from scratch,
assuming Google are still able to be generous with their existing code.
Thanks,
Dan
Re: Can we get rid of javacript/container/ifpc.js?
Posted by Cassie <do...@apache.org>.
Alright, I'll hold tight on this a little longer. I will also pose another
question:
Can we get rid of javascript/container/json.js?
This is another duplicate library of features/core/json.js. It also seems
like no one is using it.
Please speak up if you think this needs to stick around.
Thanks!
- Cassie
On Tue, Mar 25, 2008 at 7:47 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, Mar 25, 2008 at 6:39 AM, Cassie <do...@apache.org> wrote:
>
> > I can not find any Shindig usages of the code inside of
> > javascript/container/ifpc.js or of ifpc_relay.html. All of the samples
> are
> > now using the rpc library.
> >
> > I would like to delete these two files in order to reduce duplication
> > inside
> > of our code base. Is there any reason for these files to stay around
> that
> > I
> > am missing? Is anybody relying on them? Thanks.
>
>
> I can't think of any reason to keep them. The legacy mapping in rpc.js
> takes
> care of dealing with parent containers that are still using ifpc, so
> there's
> really no good reason for keeping it around so far as I know. I'd leave it
> around for at least a week though -- Zhen is on vacation and I suspect
> he's
> not checking his email.
>
Re: Can we get rid of javacript/container/ifpc.js?
Posted by Kevin Brown <et...@google.com>.
On Tue, Mar 25, 2008 at 6:39 AM, Cassie <do...@apache.org> wrote:
> I can not find any Shindig usages of the code inside of
> javascript/container/ifpc.js or of ifpc_relay.html. All of the samples are
> now using the rpc library.
>
> I would like to delete these two files in order to reduce duplication
> inside
> of our code base. Is there any reason for these files to stay around that
> I
> am missing? Is anybody relying on them? Thanks.
I can't think of any reason to keep them. The legacy mapping in rpc.js takes
care of dealing with parent containers that are still using ifpc, so there's
really no good reason for keeping it around so far as I know. I'd leave it
around for at least a week though -- Zhen is on vacation and I suspect he's
not checking his email.