SimplePie
Chris J. Davis
we going to or not?
I am +1
Chris
Scott Merrill
> We have official permission to add SimplePie to Habari core, so are
> we going to or not?
+0
I don't know enough about the benefits and drawbacks.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Sean T Evans
Rich Bowen
On Aug 13, 2007, at 09:57, Scott Merrill wrote:
>
> Chris J. Davis wrote:
>> We have official permission to add SimplePie to Habari core, so are
>> we going to or not?
>
> +0
>
> I don't know enough about the benefits and drawbacks.
Ya. Ditto. +0.
If you guys want it, and it helps us along, then, sure, stick it in
core. If it gets us better Atom/RSS support, awesome. If it turns out
to not be a good idea, we can always drop it later, right?
--
What the world needs is more geniuses with humility, there are so few
of us left.
Oscar Levant
Owen Winkler
>
> We have official permission to add SimplePie to Habari core, so are
> we going to or not?
>
-1.
SimplePie is a good tool to address a single site's RSS needs, but I
don't think it is suited as a core part of Habari.
Ignoring the packaged archive which includes almost 20k in
testing/demo php and much more in images, css, and flash, the 286k
simplepie.inc file incorporates many functions that duplicate
functionality that we're already trying to build in the core in a more
OOP fashion, or present output options that seem inappropriate for our
project.
An example of functions of questionable utility to Habari include the
myriad of subscribe_*() functions, like subscribe_eskobo(). This
returns a URL that you can use in a link to subscribe to a feed in
with the Eskobo sevice. This feels outside of the purview of what
Habari should be doing.
SimplePie_File is a class with a single method for accessing remote
files via HTTP. It does this via fsockopen or curl, depending on
what's present on the system or if fsockopen is demanded. Aside from
being a duplicate to our RemoteRequest class and it's subclasses
(which might not currently be as conforming to W3C spec, but are more
flexible/extensible in how they are constructed), it employs the
idna_convert class for converting internationalized domain names.
This code is LGPL.
Also, SimplePie is not strictly PHP5. While this doen't make
SimplePie incompatible with Habari source, it will make for irregular
(for Habari) language constructions in regard to objects. Whereas
Habari objects have properties like $post->content, SimplePie's item
class has methods for returning data. Sure it seems minor, but when
looking at the code from a high-level view, one might ask why all of
the code looks one way (with properties) up until you get to handling
feeds, which takes a completely different tack.
There is no question that the work done on the parser itself is the
best you can get in a library. Perhaps if we only used the parts we
needed, that would be fine. The issue I see with this is that a big
benefit of using a third-party library is in allowing someone else to
maintain it.
If we hacked apart SimplePie to include only those parts we needed,
while adhering to our coding standards, we'd be maintaining SimplePie
code too. We may end up manually synchronizing the significantly
altered SimplePie in Habari with whatever changes happened in the main
SimplePie branch. Certainly this is not as easy as "dropping in"
SimplePie for feed use, which seems to be the idea here.
Finally, I'm interested to hear what specific functionality Habari
will provide that requries feed reading. Is the idea that Habari
should be packaged with libraries that might be useful for plugins or
features that are developed, but not useful for core functionality?
SimplePie doesn't create feeds, it consumes them. What part of Habari
consumes feeds?
Anyway, I'm against including SimplePie as-is. Perhaps someone has
some other suggestion as to how we can leverage the SimplePie code.
Owen
drac
>
> On 8/13/07, Chris J. Davis <c...@chrisjdavis.org> wrote:
> >
> > We have official permission to add SimplePie to Habari core, so are
> > we going to or not?
> don't think it is suited as a core part of Habari.
Fair enough. I personally would like to see SimplePie (or failing
which, some other feed reading library) included as core. I'm trying
to articulate a case for inclusion, as it were.
> [ ... ] I'm interested to hear what specific functionality Habari
> will provide that requries feed reading. Is the idea that Habari
> should be packaged with libraries that might be useful for plugins or
> features that are developed, but not useful for core functionality?
> SimplePie doesn't create feeds, it consumes them. What part of Habari
> consumes feeds?
Actually, this is precisely the usecase that I had in mind for
Habari's inclusion of SimplePie. There are currently three known
plugin usecases in the wild for consuming feeds and displaying them in
a Habari blog.
a) Lifestream
b) Flickr integration (I believe this was proposed by sfong. Apologies
if I got the author wrong)
c) del.icio asides/link blogging related plugins (I'm toying with the
idea of writing something along those lines to replace
wp-recentlinks.)
One consideration is to avoid duplication of libraries. Do we really
want to have plugins ship with SimplePie? A similiar case could
concievably be made for Prototype/Scriptaculous but we already offer a
viable alternative in JQuery. Habari currently does not include API
for consuming RSS feeds (AFAIK. I haven't been tracking SVN too
closely of late).
As a larger, perhaps more long term consideration; we will consider a
media manager for images and video at some point. Should RSS/Atom
feeds not be considered for inclusion in the same way? The first part
in integrating such content is to make RSS feeds pluggable and
available for display in the main display stream of a blog. Surely
this will be made easier by having RSS consumption built into Habari?
> Anyway, I'm against including SimplePie as-is. Perhaps someone has
> some other suggestion as to how we can leverage the SimplePie code.
I appreciate your well made points about the difficulties in making
SimplePie fit into our existing codebase. Perhaps a partial solution
lies in a Habarized wrapper around a SimplePie instance which is then
made available to plugins? It would still be simpler than writing our
own feed parsing methods.
I'm just tossing that out there as a compromise solution of sorts.
Owen Winkler
>
> On 8/13/07, Owen Winkler <epi...@gmail.com> wrote:
> >
> > On 8/13/07, Chris J. Davis <c...@chrisjdavis.org> wrote:
> > >
> > > We have official permission to add SimplePie to Habari core, so are
> > > we going to or not?
> > SimplePie is a good tool to address a single site's RSS needs, but I
> > don't think it is suited as a core part of Habari.
>
> Fair enough. I personally would like to see SimplePie (or failing
> which, some other feed reading library) included as core. I'm trying
> to articulate a case for inclusion, as it were.
I see a case for including a feed reading library in core; However,
SimplePie brings a lot more functionality than what we require for
something that the core of the software is not likely to use.
If there was a library that better suited Habari, even if it wasn't as
good at parsing, I would more likely recommend it over SimplePie. I
think SimplePie would be a band-aid for an injury Habari doesn't have.
Others might deplore the suggestion that PHP comes with SimpleXML for
accessing XML/feed data. The fact is that although SimpleXML has its
faults in parsing (which is not something I deny or will debate), it
provides a PHP5 method in the spirit of Habari's API for accessing XML
data. If some better RSS/Atom library were to offer as simple access
into feeds as SimpleXML, I would sign on immediately. SimplePie is
not that library, and I don't believe that it's worthwhile to include
3rd-party code that doesn't follow our API style.
I don't believe the need for this feature is so strong that we need to
jump at this option, either. While it is commonly accepted that
SimplePie is good at it's job, perhaps there is some other library
available that is more Habari-like in its implementation. Has anyone
investigated any other options for implementing feed clients?
> I appreciate your well made points about the difficulties in making
> SimplePie fit into our existing codebase. Perhaps a partial solution
> lies in a Habarized wrapper around a SimplePie instance which is then
> made available to plugins? It would still be simpler than writing our
> own feed parsing methods.
Perhaps a wrapper is the way to go, but assuming you went that far,
why not design a working property-based class, and implement it by
filling it in with SimplePie code? If so, you're not writing your own
feed parsing methods, you leverage the feed parsing prowess of
SimplePie, and you get a clean, Habari-friendly API for feeds. It may
be a bit more work overall, and perhaps a wrapper around SimplePie
initially could make the transition faster, but an eventual goal would
be to not include SimplePie at all.
The single SimplePie file itself is 3/4 of the size of all of the
files currently in Habari's /system/classes. That leaves me
astonished - you might well call our software "The Habari plugin for
SimplePie".
Owen
Chris J. Davis
thought out reason behind it, so this issue is tabled for now. We
need to have a conversation about what we want from a library like
this, and then decide if we need to write it ourselves, or look for
something that fits the bill.
Thanks everyone for your time on this, it wasn't wasted.
Chris
drac
>
> On 8/13/07, drac <lair...@gmail.com> wrote:
> >
> > On 8/13/07, Owen Winkler <epi...@gmail.com> wrote:
> > >
> > > On 8/13/07, Chris J. Davis <c...@chrisjdavis.org> wrote:
> > > >
> > > > We have official permission to add SimplePie to Habari core, so are
> > > > we going to or not?
> > > SimplePie is a good tool to address a single site's RSS needs, but I
> > > don't think it is suited as a core part of Habari.
> >
> > Fair enough. I personally would like to see SimplePie (or failing
> > which, some other feed reading library) included as core. I'm trying
> > to articulate a case for inclusion, as it were.
>
> I see a case for including a feed reading library in core; However,
> SimplePie brings a lot more functionality than what we require for
> something that the core of the software is not likely to use.
I know this is very uh ... pie-in-the-sky stuff, but is it
inconceivable that we may adopt RSS/Atomish notifications for update
beacons in the future? I know this sounds like a retroactive
justification for the inclusion of an admittedly large library but
having Atom/RSS parsing support in core is a "good thing", IMHO.
I am thinking of notifications such as "dashboard" entries too, but I
won't say it. Oops. Too late. *grin*
> I don't believe the need for this feature is so strong that we need to
> jump at this option, either. While it is commonly accepted that
> SimplePie is good at it's job, perhaps there is some other library
> available that is more Habari-like in its implementation. Has anyone
> investigated any other options for implementing feed clients?
My investigation (for a different project) at the beginning of this
year yielded the oft referred and infrequently updated MagpieRSS and
SimplePie as the leading (perhaps only) candidates available in PHP.
Perhaps there are others? I certainly didn't see any.
> > Perhaps a partial solution lies in a Habarized wrapper around a SimplePie instance
>
> Perhaps a wrapper is the way to go, but assuming you went that far,
> why not design a working property-based class, and implement it by
> filling it in with SimplePie code?
Because a wrapper would make SimplePie and its subsequent minor
updates a drop-in replacement instead of a more complicated and error
prone copy-paste diffing job.
I think there may be a contract of sorts that 1.0+ releases won't
change the SimplePie API methods around too much; which should aid the
job. Provided we use SimplePie for the moment, a wrapper seems to be
the more maintainable route forward.
We don't need to develop the SimplePie functionality ourselves, yet we
keep the interface more or less conformant to the Habari API method.
This is not dissimilar in intent to the DatabaseConnection facade.
> The single SimplePie file itself is 3/4 of the size of all of the
> files currently in Habari's /system/classes. That leaves me
> astonished - you might well call our software "The Habari plugin for
> SimplePie".
Hmmm, I think someone else made the same case the first time we had
this same case.
From my admittedly subjective perspective, if we do want to include
RSS parsing in core and if SimplePie is the best available library for
the job - (both big IFs)
then the size of the library to do the job is an important but still
secondary consideration.
drac
more sleep and/or coffee.
Geoffrey Sneddon
On 13 Aug 2007, at 19:00, drac wrote:
> I think there may be a contract of sorts that 1.0+ releases won't
> change the SimplePie API methods around too much; which should aid the
> job. Provided we use SimplePie for the moment, a wrapper seems to be
> the more maintainable route forward.
1.x won't break the public APIs at all. 2.x (when it comes) has the
issue of being done from distributed SCM, and having higher
requirements than Habari, being PHP 5.2.
- Geoffrey Sneddon
Owen Winkler
>
> I know this is very uh ... pie-in-the-sky stuff, but is it
> inconceivable that we may adopt RSS/Atomish notifications for update
> beacons in the future? I know this sounds like a retroactive
> justification for the inclusion of an admittedly large library but
> having Atom/RSS parsing support in core is a "good thing", IMHO.
Atom/RSS parsing support in core would be a good thing. I don't
discount that at all.
Using Atom/RSS for the update beacon won't work, I think, because of
the specific nature of the data in the beacon. In other words, we'd
be shoehorning what information we need to convey into a format that
isn't built as well for it as the plain XML we already have.
Yes, it's a huge library for such a small feature.
> I am thinking of notifications such as "dashboard" entries too, but I
> won't say it. Oops. Too late. *grin*
Boo. :p
> > Perhaps a wrapper is the way to go, but assuming you went that far,
> > why not design a working property-based class, and implement it by
> > filling it in with SimplePie code?
>
> Because a wrapper would make SimplePie and its subsequent minor
> updates a drop-in replacement instead of a more complicated and error
> prone copy-paste diffing job.
> I think there may be a contract of sorts that 1.0+ releases won't
> change the SimplePie API methods around too much; which should aid the
> job. Provided we use SimplePie for the moment, a wrapper seems to be
> the more maintainable route forward.
>
> We don't need to develop the SimplePie functionality ourselves, yet we
> keep the interface more or less conformant to the Habari API method.
The issues that I see with SimplePie boil down to these:
* Has several features we don't need.
* Duplicates some features we already have.
* Doesn't provide Habari-like API.
* Is very large.
A wrapper is a nice temporary solution for getting us an API for a new
library that doesn't have these issues, but as a permanent solution it
makes a few of those issues worse.
> From my admittedly subjective perspective, if we do want to include
> RSS parsing in core and if SimplePie is the best available library for
> the job - (both big IFs)
> then the size of the library to do the job is an important but still
> secondary consideration.
I don't think "best available" is a good argument for compromising
principles, and I don't know that "best" (whatever that consists of)
is necessarily what this particular feature requires.
Anyway, I think I've said all I meant to on this topic. Unless some
other point comes up, I'm still at a -1 to include SimplePie in core.
Perhaps we would be better served to discuss in general how we can
better integrate shared libraries in Habari? Consider that some
library in the future becomes well-used before Habari integrates its
specific features into the core. If several plugins all adopt this
library, they may all include their own copies, leading to mayhem. Is
there something we can do to mitigate this issue? Using the inclusion
of SimplePie as a model, can we craft a method by which plugins can
share libraries safely in Habari, and provide a way that if we
included that library as a part of the core in the future things would
still work as expected?
Owen
sfong15
http://blog.tinyau.net/archives/2007/07/29/habari-rn-flickrrss-plugin/
I only helped testing it. SimplePie is bit heavy I have to say.
On Aug 13, 11:06 pm, drac <lairm...@gmail.com> wrote: