Tomas: Fair enough about it being a POC so not showing how to translate it. I was just concerned that it would make translation more difficult, but it looks like that concern was baseless : ).
Kyle: Well, I think I’m mostly persuaded. That said, I think it’s a shame that Koha has no priorities. I also want Koha to be the fastest, slickest most useful ILS in the world, but I think more collaboration and cooperation would help ensure that. I think that’s what folk were trying to do with that roadmap idea a while back. I don’t think <https://wiki.koha-community.org/wiki/Roadmap_for_Koha> https://wiki.koha-community.org/wiki/Roadmap_for_Koha has been updated in about 1.5 years though. I suppose it says it’s a memorandum of intent rather than a strategic plan. While I’m not saying that DSpace has it entirely right, they seem to be a lot more strategic in their planning. They introduced a REST API 3 years ago. They have (optional) SPARQL endpoints in their latest version. That said, DSpace is a less complex application, and it has a smaller core team which makes reaching consensus a lot easier. They still accept contributions outside the strategy. I had a pull request accepted a while ago, but it was a small commit which didn’t really interfere with their main work. I’m not that familiar with Evergreen, but, Galen, isn’t there an oversight board which discusses strategic issues? I suppose we don’t have to do X just because everyone else is doing X, but I wonder sometimes if Koha could use more direction. Take ElasticSearch for instance. We could’ve made a Koha 4, and replaced Zebra with ElasticSearch completely. It would’ve been a big effort, but certainly a worthwhile one. I suppose that would’ve run the risks of people continuing to provide patches for the 3.x branch while work continued on Koha 4… and thus created a divide. We could’ve said no more development on 3.x and targeted work on 4.x only, but that could have stifled innovation and turned people off Koha as well. Maybe it’s just a case of the grass being greener for me. I mean… I’m not a frequent contributor to Koha at the moment, so I could just be out of the loop as well. I think Jonathan and Katrin mentioned the developer meetings earlier. Perhaps that’s enough of a venue for strategic direction. I imagine the core contributors for Koha do tend to share a sense of direction? I think we’ve seen that with ElasticSearch, Plack, Bootstrap. Obviously some individuals and organisations spearhead those. I suppose being someone who contributes infrequently… I would like to work more with people because I can’t necessarily devote 100% of my time to improving one part of Koha. But if there were a particular goal where we could all pitch code in… I suppose at the moment the best way to do that is by testing patches and providing sign offs. But because there’s a lack of priorities… the patches awaiting sign off might be for things that won’t necessarily make Koha faster and slicker. I suppose it just goes back to us all wanting Koha to be the best. I just wonder if there are ways that we could improve how we do things to be more effective and efficient. For my part, I’d love to work on a better API for importing records. I fear though that I might not have enough clout in the community to actualize that though. Nor do I know exactly how to make that API better, since my use cases represent just a few of all use cases. I suppose that’s why people make RFCs yet I feel like many RFCs get mostly ignored. I suppose if Koha did have more direction, I would still be in the same or worse position if the community decided that improving the import API wasn’t a priority. I suppose at the moment the koha-devel listserv and the developer meetings are the venue to discuss these things, and if something catches the eye, they get discussed – like this React idea : ). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Kyle Hall [mailto:kyle.m.h...@gmail.com] Sent: Thursday, 22 September 2016 12:28 AM To: David Cook <dc...@prosentient.com.au> Cc: Owen Leonard <oleon...@myacpl.org>; Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] To React or not to React On Tue, Sep 20, 2016 at 6:29 PM, David Cook <dc...@prosentient.com.au <mailto:dc...@prosentient.com.au> > wrote: I think it differs in that a search engine and a RESTful API adds core functionality. Without them, we can’t really search or expose services. We already have a JS UI toolkit, which seems to be working fine. Yes, jQuery UI does work just fine, however libs like React really solve a different problem domain. In fact, it's expected that jQuery will be used within React for API access. Why do you say that React is necessary and long overdue? In terms of your email, do you mean that it lets you do more with less code? I’m not necessarily opposed to that. I do get annoyed by having to write so much code to achieve small things at times. That's the problem React solves! I takes *so* much less code to write an equivilent feature with React than it would with html and jQuery dom manipulation. I was actually a bit shocked at how fast I was able to rewrite the item messages feature in React. I suppose I’m curious as to the motivation behind React at this point. Aren’t there higher priorities for Koha right now? I suppose maybe that’s just my own naïveté speaking, and part of the joy of having so many developers on Koha is that we can all focus on different aspects of the system. That's the great thing about Koha as a community. Koha has no priorities, but each stakeholder can. I'm sure your priorities could be much different from my, but they can be pursued simultaneously! Yet, shouldn’t there be some cohesion? Are our interfaces going to be a combination of plain JS, jQuery, Bootstrap, React, Yui (if it’s still used), and whatever other libraries we’re still using? This is what I mean about bolting things on. Then again, if React really does allow for cleaner interfaces, perhaps we’d find it taking over our interfaces rapidly, and it would become a de facto standard. I don’t know. There's only one way to find out ; ) In all seriousness, I just want Koha to be the fastest, slickest most useful ILS in the world. I want it to be an absolute pleasure to use. And I think this is a necessary milestone to achieving that goal. Kyle David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Kyle Hall [mailto:kyle.m.h...@gmail.com <mailto:kyle.m.h...@gmail.com> ] Sent: Tuesday, 20 September 2016 3:31 PM To: David Cook <dc...@prosentient.com.au <mailto:dc...@prosentient.com.au> > Cc: Owen Leonard <oleon...@myacpl.org <mailto:oleon...@myacpl.org> >; Koha Devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] To React or not to React For my part, I don't know if we need to keep bolting on more new and shiny to Koha. ElasticSearch makes sense. A REST API makes sense. Fixing broken things or adding missing essential functionality. I'm not sure how this differs from Koha adding Zebra, adding Elastic or adding a restful api. To me, this is not a matter of adding new for the sake of new ( React isn't even new at this point ) but of adding something that is necessary and long overdue. The question isn't about needing React or not, it's about the need for a modern JS UI toolkit to take advantage of our svc and rest api's without the need to write crazy amounts of code to make it work with just jQuery. Take a look at the javascript file for the holds table and you'll see what I mean. A React implementation of it would be *so* much cleaner and easier to understand for everyone. Please don't ask me to rewrite it as a poc though ; ) I *will* be happy to rewrite it post-adoption. Also, how would this React POC go in terms of translations? React is just Javascript, and is translated the same way translate all our other js files. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 > -----Original Message----- > From: koha-devel-boun...@lists.koha-community.org > <mailto:koha-devel-boun...@lists.koha-community.org> [mailto:koha-devel- > <mailto:koha-devel-> > boun...@lists.koha-community.org <mailto:boun...@lists.koha-community.org> ] > On Behalf Of Owen Leonard > Sent: Monday, 19 September 2016 11:33 PM > To: Koha Devel <koha-devel@lists.koha-community.org > <mailto:koha-devel@lists.koha-community.org> > > Subject: Re: [Koha-devel] To React or not to React > > > Another thing is that you need nodejs to compile it so is another > > thing to throw on the stack. > > Isn't this the kind of dependency requirement that killed my request to > introduce a front-end build tool like Grunt or Gulp? > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > <mailto:Koha-devel@lists.koha-community.org> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ <http://community.org/> bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
