GNOME Bugzilla – Bug 484608
[PLUGIN-MOVE] Move neon from -bad to -good
Last modified: 2008-08-20 17:19:11 UTC
Hi, would be nice if neon could be moved to gst-plugins-good with the next release and get a primary rank to make it the default http element. Is there anything left to be done except docs? Bye
Other stuff I found that would be nice to be done: - HTTP Authentication, probably either by having it in the supplied URI (http://user:pass@blablab.com/foo/bar) or having properties. - Do something with the stop of the seek segments, i.e. include the end in the Range header field and EOS (i.e. GST_FLOW_UNEXPECTED) if trying to read after it. Will probably care for the latter and docs later...
Why not only move it but make it primary too? What are its advantages over gnomevfssrc? (Just curious) One thing that definitely needs to be fixed is neonhttpsrc's rubbish/substandard error reporting (categories, messages, etc.). Another issue is, if I'm not mistaken, that gnomevfssrc takes proxy settings from GConf by default. This is probably desirably on a gnome desktop (and will have no effect if the user has not set up gnome). In any case, if this is true it means gnome applications need fixing to configure the proxy settings and all that.
The Gnome proxy settings are also exported via the environment variables the neonhttpsrc accepts. The advantage over gnomevfssrc is, that it allows seeking and doesn't need gnomevfs and it's load of dependencies :) I'll take a look at the error reporting later...
oh, and that it isn't going to be deprecated soon of course ;)
My impression of neonhttpsrc every time I try it is that it's very incomplete and buggy. It certainly isn't even close to ready for a move (and it's even less close to being a viable replacement for gnomevfssrc by default). It needs a real maintainer if you want to get it into good - want to volunteer?
> My impression of neonhttpsrc every time I try it is that it's very incomplete > and buggy. It certainly isn't even close to ready for a move (and it's even > less close to being a viable replacement for gnomevfssrc by default). That pretty much sums up my feelings about neonhttpsrc as well.
Do you guys have some examples where neonhttpsrc has bugs? Would be nice to get them fixed then :) In any case, I would be fine with maintaining it... only have to finally find some time to get stuff done :/
Do we still want/need this now that we have souphttpsrc in -good? Does libneon support async/non-blocking network operations btw?
IMHO this can be closed now... there's no reason to prefer neon over libsoup :)