Re: [Koha-devel] [Koha-patches] [PATCH] Removed RSS Option from UI
Can someone point me at the reasoning for removing RSS features from the user interface, please? Are they currently broken and, if so, where's the bug report? Thanks, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
This is probably not what you think it is. It's not like we're removing RSS feeds from the entire system. We're actually just removing UI elements for a messaging system feature that never even existed. To clarify what happened, please run this query on your system: SELECT * FROM message_transport_types; All you should see is email and sms. These represent the ways the messaging system can send out messages. However, in the spec that I had to work with, the UI mockup contained an option for an rss transport type that had not existed before. At first, I thought I'd add go ahead and add another transport type so that I could implement what I saw in the mockup. But later on, when I realized that messaging system didn't have any support for this transport mechanism, I decided that it was pointless to pretend that it did, so I got rid of it. This was also my first encounter with the messaging system, and I was trying to figure out what was going on. I was just undoing something that I shouldn't have even done in the first place. No real functionality disappeared as a result of this. --beppu On Wed, Feb 4, 2009 at 1:08 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Can someone point me at the reasoning for removing RSS features from the user interface, please? Are they currently broken and, if so, where's the bug report?
Thanks, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi John Thanks for clarification. It would be great to have a summary or a link to RFC in your patches, so that we can better catch the general purpose of and the general architecture implied by the handfull of patches sent. Cheers. -- Henri-Damien LAURENT John Beppu a écrit :
This is probably not what you think it is. It's not like we're removing RSS feeds from the entire system. We're actually just removing UI elements for a messaging system feature that never even existed.
To clarify what happened, please run this query on your system:
SELECT * FROM message_transport_types;
All you should see is email and sms. These represent the ways the messaging system can send out messages.
However, in the spec that I had to work with, the UI mockup contained an option for an rss transport type that had not existed before. At first, I thought I'd add go ahead and add another transport type so that I could implement what I saw in the mockup. But later on, when I realized that messaging system didn't have any support for this transport mechanism, I decided that it was pointless to pretend that it did, so I got rid of it.
This was also my first encounter with the messaging system, and I was trying to figure out what was going on. I was just undoing something that I shouldn't have even done in the first place. No real functionality disappeared as a result of this.
--beppu
Sure. The purpose of this big set of patches was to make it possible for koha to send notifications to borrowers upon checkout and check-in. Next, you might be wondering why this seemingly simple task took 17 patches to accomplish. ;-) First, the high number of patches reflects the back and forth process of showing Dan and Galen what I had done and then going back to fix the flaws that they found in my work. Second, the specs required a high degree of configurability for this feature, so it wasn't just a matter of sending a notification when a check-in or checkout event happened. I also had to implement ways to allow administrators to define the conditions for when alerts could be sent out. (The UI for this is in admin/item_circulation_alerts.pl .) I also had to make it possible for users to set whether they wanted to receive their notifications via email or sms. Third, the spec required that multiple checkout or check-in events should be aggregated together. For example, if you checked out 10 books, you should only get 1 notification that lists the 10 books you checked out. You should NOT get 10 separate notifications, because that would be annoying. Anyway, to make this possible, I had to extend the messaging system so that I could find pending messages in the message_queue table and add more text to them. (The code for most of this work is in C4/Message.pm .) Hopefully, this clarifies the overall intent of this patch set. --beppu On Wed, Feb 4, 2009 at 1:42 AM, LAURENT Henri-Damien < henridamien@koha-fr.org> wrote:
Hi John Thanks for clarification. It would be great to have a summary or a link to RFC in your patches, so that we can better catch the general purpose of and the general architecture implied by the handfull of patches sent. Cheers. -- Henri-Damien LAURENT
Hi John Thanks for clarification. It would be great to have a summary or a link to RFC in your patches, so that we can better catch the general purpose of and the general architecture implied by the handfull of patches sent, just as you have just done for memcached (great by the way, even though i am somewhat disappointed by the quite poor improvement it brings. I was hoping more.). Cheers. -- Henri-Damien LAURENT John Beppu a écrit :
This is probably not what you think it is. It's not like we're removing RSS feeds from the entire system. We're actually just removing UI elements for a messaging system feature that never even existed.
To clarify what happened, please run this query on your system:
SELECT * FROM message_transport_types;
All you should see is email and sms. These represent the ways the messaging system can send out messages.
However, in the spec that I had to work with, the UI mockup contained an option for an rss transport type that had not existed before. At first, I thought I'd add go ahead and add another transport type so that I could implement what I saw in the mockup. But later on, when I realized that messaging system didn't have any support for this transport mechanism, I decided that it was pointless to pretend that it did, so I got rid of it.
This was also my first encounter with the messaging system, and I was trying to figure out what was going on. I was just undoing something that I shouldn't have even done in the first place. No real functionality disappeared as a result of this.
--beppu
I agree that it was quite a disappointment to only see about 10% improvement in the request rate despite eliminating so many database queries. I was expecting a much bigger speed increase, too. If you want to benchmark it yourself, here's how I ran apache bench against koha: ab -H "Cookie: CGISESSID=89bb8e329080a90a82e762e280ae4d14" -c 2 -n 20 http://intranet.mydomain.com:8080/cgi-bin/koha/mainpage.pl ^Put that all on one line and change the session id to something that's valid for your system. --beppu PS: I wasn't sure if the memcached patches made it to patches@koha.org. Thanks for verifying that my emails actually made it through. On Wed, Feb 4, 2009 at 1:53 AM, LAURENT Henri-Damien < henridamien.laurent@biblibre.com> wrote:
just as you have just done for memcached (great by the way, even though i am somewhat disappointed by the quite poor improvement it brings. I was hoping more.). Cheers. -- Henri-Damien LAURENT
John Beppu a écrit :
I agree that it was quite a disappointment to only see about 10% improvement in the request rate despite eliminating so many database queries. I was expecting a much bigger speed increase, too. my bet is that C4::Context cleaning will be the best improvement source. As Frederic D. has already pointed, each page call read something like 26 times the config.xml, a lot of sessions are created on mySQL... Marc C. at BibLibre spend some time on that but could not succeed yet. It's still on his roadmap though.
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
While it is the obvious "core" of DB access in Context, it is not the only target for memcached efficiency, in my mind. That is because the access is rather straight-forward retrieving preferences (that are already cached for the process by Koha). To me, the best targets are the sections that require a lot of computation to build an otherwise static object, like MARC frameworks or a fully parsed MARCXML object. The reason the caching should be "better" there is because it skips both disk and CPU loads, and the data is in a more highly processed state. The speed of retrieving a syspref like marcflavour won''t matter as much because when you already have the correct object built, you don't need to check it. Or that's the idea, anyway... --Joe On Wed, Feb 4, 2009 at 6:14 AM, paul POULAIN <paul.poulain@biblibre.com>wrote:
John Beppu a écrit :
I agree that it was quite a disappointment to only see about 10% improvement in the request rate despite eliminating so many database queries. I was expecting a much bigger speed increase, too. my bet is that C4::Context cleaning will be the best improvement source. As Frederic D. has already pointed, each page call read something like 26 times the config.xml, a lot of sessions are created on mySQL... Marc C. at BibLibre spend some time on that but could not succeed yet. It's still on his roadmap though.
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Joe Atzberger wrote:
While it is the obvious "core" of DB access in Context, it is not the only target for memcached efficiency, in my mind. That is because the access is rather straight-forward retrieving preferences (that are already cached for the process by Koha).
To me, the best targets are the sections that require a lot of computation to build an otherwise static object, like MARC frameworks or a fully parsed MARCXML object. The reason the caching should be "better" there is because it skips both disk and CPU loads, and the data is in a more highly processed state. The speed of retrieving a syspref like marcflavour won''t matter as much because when you already have the correct object built, you don't need to check it. Or that's the idea, anyway...
This harks back to installing an ORM like DBIx::Class into Koha. On the last ORM project I worked on, we implemented one layer of abstraction between perl's DBI and the app itself. Within that layer, we could flag *any* table as being read-only and/or cache-able. With this feature, caching and the attendant increase in efficiency was available to the app without having to change a single line of app code. This is a good reason to provide an abstraction layer between the ORM we end up using and the Koha app. In that layer we can do things like cache, as well as capture metrics (very usfull for optimisation). Of course, a cache is pretty useless unless perl itself is cached using mod_perl or similar. Food for thought for Koha's future ORM. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Maybe this world is another planet's Hell. -- Aldous Huxley
On Wed, Feb 4, 2009 at 5:50 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Of course, a cache is pretty useless unless perl itself is cached using mod_perl or similar.
Although I agree the ORM layer really accelerates how quickly you can get benefit out of memcached, it is certainly incorrect that mod_perl is required to get any benefit. The initial testing has already shown modest benefit. As another example, you have a fully parsed MARC::Record object representation for a given biblio. You can store that object away, and the next time you need to reference it (when a user clicks for the details page, or the MARC page, etc.) you can retrieve and use it without having to call: - biblioitems for the marcxml - MARC::Record->new_from_xml That example may not be something we do in practice (better targets abound), but you can see conceptually where the benefit can kick in w/o mod_perl. In particular, if you have a lot of Apache front-ends, you can use a consolidated cache server and get the benefit across all (one copy of the object available to all of them). At the end of the day, I think we are very close to seeing real production-scenario benefit from memcached, and still somewhat far from using mod_perl. In large part that is because mod_perl requires broad changes to the codebase before the first benefit is returned whereas memcached can slip in optionally now. --Joe
As another example, you have a fully parsed MARC::Record object representation for a given biblio. You can store that object away, and the next time you need to reference it (when a user clicks for the details page, or the MARC page, etc.) you can retrieve and use it without having to call:
* biblioitems for the marcxml * MARC::Record->new_from_xml
Biblio record objects are heavy weight and processing hungry to build up and process. XSLT.pm seems to me a good place to examine in order to find out improvement opportunities... For example: my $style_doc = $parser->parse_file($xslfile); my $stylesheet = $xslt->parse_stylesheet($style_doc); XSLT stylesheet object is yet rebuild for each biblio record to transform. It could be cached per session in script global variable: immediat benefit on result page. And it could be cached with Memcached. Same applies with framework and authorized values. -- Frédéric
John Beppu <john.beppu@liblime.com> wrote:
This was also my first encounter with the messaging system, and I was trying to figure out what was going on. I was just undoing something that I shouldn't have even done in the first place. No real functionality disappeared as a result of this.
OK and thanks for the explanation. I guess I should have checked the annotations for those lines to see how they appeared. If you could mention "undo" or similar in the log message, that would help me avoid making a fool of myself in public again ;-) -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
No problem. I'll use the word "undo" the next time I do something like that. I'm still kind of a n00b to this code base, so it'll probably happen again. --beppu On Wed, Feb 4, 2009 at 1:57 AM, MJ Ray <mjr@phonecoop.coop> wrote:
This was also my first encounter with the messaging system, and I was
John Beppu <john.beppu@liblime.com> wrote: trying
to figure out what was going on. I was just undoing something that I shouldn't have even done in the first place. No real functionality disappeared as a result of this.
OK and thanks for the explanation. I guess I should have checked the annotations for those lines to see how they appeared. If you could mention "undo" or similar in the log message, that would help me avoid making a fool of myself in public again ;-) -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
participants (8)
-
Frederic Demians -
Joe Atzberger -
John Beppu -
LAURENT Henri-Damien -
LAURENT Henri-Damien -
MJ Ray -
paul POULAIN -
Rick Welykochy