Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Item search #4

Open
kristebo opened this issue Sep 11, 2018 · 6 comments
Open

Item search #4

kristebo opened this issue Sep 11, 2018 · 6 comments

Comments

@kristebo
Copy link

Thsi could either be a integration with oria or a searchfield.

What is the problem with a pagiante/search querry?

@danmichaelo
Copy link
Member

Som kind of simple API that exposes Bibrex items to the outside world is certainly something I have been thinking about.

Apart from Oria integration (which is well defined, but a hassle), could you elaborate a little on the use case you have in your mind? Given the small number of things available I'm not sure if I understand the need for search per se.

@kristebo
Copy link
Author

first of all: scalability/usability of bibrex. The numer of items will go up. (I will add a bunch)

Usecase 1:
I was thinking if an user search for "howto raspberry pie", the user would get hits on some litterature, some articles and in addition hardware to try stuff on.

Usecase 2 (This has been talked about):
A student breaks laptop, needs tools, knows that the library can provide, but doesn't know what. searches for "broken laptop" or "screwdriver" and gets hits on driver and bits. This will need meta data.

@danmichaelo
Copy link
Member

I split out Oria integration in #5. We could discuss other ways of providing search/discoverability here.

One option is to make Bibrex itself a "public" app by including some user-facing views. Another one to provide APIs, perhaps RSS generation, and integrate with the library webpages. We already have pages like Contents of the Science Library, that would benefit from a dynamic list of available things. Including the list in Vortex should also make it google-able in principle.

@kristebo
Copy link
Author

Both API- and user-facing views can solve this.

My thoughts:
cons for an API:

  • need authentication of API-usage(?)
  • integration.
  • dynamically generated content for Vortex

pros for an API:

  • integration.

Cons with "public":

  • user authentication (SSO) (?)
  • security

Pros with "public"

  • no integration
  • no dynamically generated content for vortex.

@danmichaelo
Copy link
Member

I was thinking about a simple, public (no auth) API with routes perhaps like this:

  • /api/things?query : returns list of things
  • /api/things/{} : return thing with list of items and their availability
  • /api/items?query : returns list of items

@kristebo
Copy link
Author

Those three should be easy to make in /routes/api.php .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants