Hey All, Writing the LibraryThing book cover module has really got my brain in full gear. I've been thinking about how nice it would be to add an internal cover system to Koha. That way, a library could specify the exact cover they want if they so wish. Here's what I'm imagining. A new ItemImages.pm ( BookCovers.pm, BookJackets.pm, what have you... ) This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules. Another module ( say LocalCovers ) would act as a caching system. Librarians would then at the time of cataloging, but able to search various sources for book jackets, and choose one to download and save for that bib record. A set of preferences would allow for a cascading selection of sources from which to display book covers. For example, a library could have the system set up to look for a locally stored book cover first. If one is not found, it checks LibraryThing for one, if one is not found there, it then uses an Amazon book cover. Possible Issues: Do any of the cover API's have Terms of Service that could pose a problem to such an system? ( For example, can we cache amazon.com images, or must they always be links? ) The existing C4::External modules would need to be modified. Where should local/cached covers be stored? Filesystem and/or MySQL blob? Any and all opinions welcome, Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
IIRC, Amazon was pretty strict about caching, limiting you to holding images for only 24 hours. That makes building a system around it significantly less desirable. The other problem you will have is that if the server is fetching all the images from Google, a busy site will trip their anti-harvesting protection and get the IP blocked. Ideally, I'd want all the jacket requests and cascading to be happening on the client side. Barring that, it at least has to be part of an AJAX request to the Koha server. Otherwise you're blocking the entire page load while you are waiting serially for 4 or 5 (or more) servers to respond. The reason you can't just do it as a dynamic response to a regular HTTP .jpg request is that you are obligated by all (or almost all?) the terms of service to put a link and/or a credit attribution in there when the image is displayed. And of course you wouldn't know ahead of time which link/credit it would be, and the dynamic response to a static request would effectively conceal the original source such that no client side logic could be used. We should also go ahead and say whether the proposed system will support showing multiple jackets (for the same item) simultaneously. I imagine that would be the single best way to evaluate the coverage and quality of various sources, to know which to enable, and in what priorities. --Joe On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Hey All, Writing the LibraryThing book cover module has really got my brain in full gear. I've been thinking about how nice it would be to add an internal cover system to Koha. That way, a library could specify the exact cover they want if they so wish. Here's what I'm imagining.
A new ItemImages.pm ( BookCovers.pm, BookJackets.pm, what have you... )
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Another module ( say LocalCovers ) would act as a caching system. Librarians would then at the time of cataloging, but able to search various sources for book jackets, and choose one to download and save for that bib record.
A set of preferences would allow for a cascading selection of sources from which to display book covers. For example, a library could have the system set up to look for a locally stored book cover first. If one is not found, it checks LibraryThing for one, if one is not found there, it then uses an Amazon book cover.
Possible Issues: Do any of the cover API's have Terms of Service that could pose a problem to such an system? ( For example, can we cache amazon.com images, or must they always be links? ) The existing C4::External modules would need to be modified. Where should local/cached covers be stored? Filesystem and/or MySQL blob?
Any and all opinions welcome, Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
Comments inline... On Thu, 2009-09-17 at 12:29 -0400, Joe Atzberger wrote:
IIRC, Amazon was pretty strict about caching, limiting you to holding images for only 24 hours. That makes building a system around it significantly less desirable.
You could conceivably add a cache life-time to the LocalCovers backend. You will have to store the images somewhere, mysql or memcached would allow you to set an extra property like that I'm sure. Doing it on the file system would be a bit more complex. Then you would have to be able to set the cache life-time from the BookCover's individual services backends, like BookCovers::Amazon would have a ( hard coded? ) cache-life of 24 hours that would be passed to the LocalCovers backend with the image to cache.
The other problem you will have is that if the server is fetching all the images from Google, a busy site will trip their anti-harvesting protection and get the IP blocked.
This is already a problem I expect. The solution is to cache images locally so that subsequent requests pull from our server instead of Google's. Having an abstract cover module would probably help this case. Images would be cached more readily, and if cascading is built in then when Google blocks you it will go on to query another service provider.
Ideally, I'd want all the jacket requests and cascading to be happening on the client side. Barring that, it at least has to be part of an AJAX request to the Koha server. Otherwise you're blocking the entire page load while you are waiting serially for 4 or 5 (or more) servers to respond. The reason you can't just do it as a dynamic response to a regular HTTP .jpg request is that you are obligated by all (or almost all?) the terms of service to put a link and/or a credit attribution in there when the image is displayed. And of course you wouldn't know ahead of time which link/credit it would be, and the dynamic response to a static request would effectively conceal the original source such that no client side logic could be used.
I agree that we will want to handle this with AJAX. No sense making the patron or staff wait for the page to load just for the cover image. Perhaps we can tie the AJAX request to the BookCovers module?
We should also go ahead and say whether the proposed system will support showing multiple jackets (for the same item) simultaneously. I imagine that would be the single best way to evaluate the coverage and quality of various sources, to know which to enable, and in what priorities.
This could be added to the staff interface down the road. A little AJAX powered pop-up window to choose the cover image to cache. That way the cache could be updated/set manually. Of course we would then want some way to store that setting. Along with the image set a property basically saying 'staff prefers images for this biblionumber to come from this service'.
--Joe
Thanks Joe. Food for thought :)
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote: Hey All, Writing the LibraryThing book cover module has really got my brain in full gear. I've been thinking about how nice it would be to add an internal cover system to Koha. That way, a library could specify the exact cover they want if they so wish. Here's what I'm imagining.
A new ItemImages.pm ( BookCovers.pm, BookJackets.pm, what have you... )
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Another module ( say LocalCovers ) would act as a caching system. Librarians would then at the time of cataloging, but able to search various sources for book jackets, and choose one to download and save for that bib record.
A set of preferences would allow for a cascading selection of sources from which to display book covers. For example, a library could have the system set up to look for a locally stored book cover first. If one is not found, it checks LibraryThing for one, if one is not found there, it then uses an Amazon book cover.
Possible Issues: Do any of the cover API's have Terms of Service that could pose a problem to such an system? ( For example, can we cache amazon.com images, or must they always be links? ) The existing C4::External modules would need to be modified. Where should local/cached covers be stored? Filesystem and/or MySQL blob?
Any and all opinions welcome, Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
Hi, On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
Selecting and storing images locally for all holdings sounds like a pain. I can imagine a cooperatively held db (hello, koha foundation) of records that look like: isbn/issn/other globally unique id that identifies the holding in a way that makes searches possible url to images (front, back, etc) - maybe they're on flickr, or in amazon land image license and/or attribution statement caching limits who updated when updated And some simple REST style api that allowed a module to display the attribution and use the image url directly for display or via a (potentially caching) proxy for local library networks that might require it. And a mechanism for adding/updating records to the cooperatively held db. And for automatically using them maybe based on who updated them in case some folks turn out to be bad at it. A variation -- instead the central db providing the look up service. It could provide just the collective DB with your local koha instance subscribing to updates. So, the user load of the lookup is local but we get the benefit of sharing the effort of selecting images. (Reinvention of usenet data flow architecture sort of.) -reed On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
What I have in mind would make selecting images optional. Here is a thought scenario: Let's say that you prefer to use amazon images for your book covers, but a few books have no cover or the wrong cover from amazon. In this instance, you would be able to upload an image locally, or force that bib to use a different service for it's book cover. So, rather than requiring you to add covers to each bib by hand, you could cascade through different cover options. Check for local image first, if not found, use amazon. Does that sound like a good idea? Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Sep 17, 2009 at 6:31 PM, Reed Wade <reedwade@gmail.com> wrote:
Selecting and storing images locally for all holdings sounds like a pain.
I can imagine a cooperatively held db (hello, koha foundation) of records that look like:
isbn/issn/other globally unique id that identifies the holding in a way that makes searches possible url to images (front, back, etc) - maybe they're on flickr, or in amazon land image license and/or attribution statement caching limits who updated when updated
And some simple REST style api that allowed a module to display the attribution and use the image url directly for display or via a (potentially caching) proxy for local library networks that might require it.
And a mechanism for adding/updating records to the cooperatively held db. And for automatically using them maybe based on who updated them in case some folks turn out to be bad at it.
A variation -- instead the central db providing the look up service. It could provide just the collective DB with your local koha instance subscribing to updates. So, the user load of the lookup is local but we get the benefit of sharing the effort of selecting images. (Reinvention of usenet data flow architecture sort of.)
-reed
On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi Kyle On Fri, Sep 18, 2009 at 11:01 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
What I have in mind would make selecting images optional. Here is a thought scenario: Let's say that you prefer to use amazon images for your book covers, but a few books have no cover or the wrong cover from amazon. In this instance, you would be able to upload an image locally, or force that bib to use a different service for it's book cover.
So, rather than requiring you to add covers to each bib by hand, you could cascade through different cover options. Check for local image first, if not found, use amazon.
Does that sound like a good idea?
I think it's a brilliant idea Cheers Rosalie Blake
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 6:31 PM, Reed Wade <reedwade@gmail.com> wrote:
Selecting and storing images locally for all holdings sounds like a pain.
I can imagine a cooperatively held db (hello, koha foundation) of records that look like:
isbn/issn/other globally unique id that identifies the holding in a way that makes searches possible url to images (front, back, etc) - maybe they're on flickr, or in amazon land image license and/or attribution statement caching limits who updated when updated
And some simple REST style api that allowed a module to display the attribution and use the image url directly for display or via a (potentially caching) proxy for local library networks that might require it.
And a mechanism for adding/updating records to the cooperatively held db. And for automatically using them maybe based on who updated them in case some folks turn out to be bad at it.
A variation -- instead the central db providing the look up service. It could provide just the collective DB with your local koha instance subscribing to updates. So, the user load of the lookup is local but we get the benefit of sharing the effort of selecting images. (Reinvention of usenet data flow architecture sort of.)
-reed
On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Certainly sounds very sensible to me. (I need to make sure folks know I have very little experience with Koha or libraries or library work flow. So, I'm liable to suggest things that wont work in practice. I just happen to work with Chris Cormack on a non-Koha project and thought it would be fun to help.) So, a separate question then becomes whether there are enough exceptions to the amazon (or similar large image set providers) to make sharing exceptions worth fooling with. I'm willing to guess that it's not -- but could always be added later as a standard option to the list. -reed On Fri, Sep 18, 2009 at 11:01 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
What I have in mind would make selecting images optional. Here is a thought scenario: Let's say that you prefer to use amazon images for your book covers, but a few books have no cover or the wrong cover from amazon. In this instance, you would be able to upload an image locally, or force that bib to use a different service for it's book cover.
So, rather than requiring you to add covers to each bib by hand, you could cascade through different cover options. Check for local image first, if not found, use amazon.
Does that sound like a good idea?
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 6:31 PM, Reed Wade <reedwade@gmail.com> wrote:
Selecting and storing images locally for all holdings sounds like a pain.
I can imagine a cooperatively held db (hello, koha foundation) of records that look like:
isbn/issn/other globally unique id that identifies the holding in a way that makes searches possible url to images (front, back, etc) - maybe they're on flickr, or in amazon land image license and/or attribution statement caching limits who updated when updated
And some simple REST style api that allowed a module to display the attribution and use the image url directly for display or via a (potentially caching) proxy for local library networks that might require it.
And a mechanism for adding/updating records to the cooperatively held db. And for automatically using them maybe based on who updated them in case some folks turn out to be bad at it.
A variation -- instead the central db providing the look up service. It could provide just the collective DB with your local koha instance subscribing to updates. So, the user load of the lookup is local but we get the benefit of sharing the effort of selecting images. (Reinvention of usenet data flow architecture sort of.)
-reed
On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
This is a great idea. I personally don't care that much about the "service" in which my jacket comes from but the idea of being able to get a picture of the cover if one isn't available. We have several items that are "unique" that we would love to have jackets of but are not part of the general trade binding. It is very helpful to the teachers when you say to them - "This is what it looks like" and they say "oh the one with the purple cover!" Of course how you obtain that jacket to store is another issue dealing with copyright etc... But hopefully librarians get that and do the right thing. Reed Wade wrote:
Certainly sounds very sensible to me.
(I need to make sure folks know I have very little experience with Koha or libraries or library work flow. So, I'm liable to suggest things that wont work in practice. I just happen to work with Chris Cormack on a non-Koha project and thought it would be fun to help.)
So, a separate question then becomes whether there are enough exceptions to the amazon (or similar large image set providers) to make sharing exceptions worth fooling with. I'm willing to guess that it's not -- but could always be added later as a standard option to the list.
-reed
On Fri, Sep 18, 2009 at 11:01 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
What I have in mind would make selecting images optional. Here is a thought scenario: Let's say that you prefer to use amazon images for your book covers, but a few books have no cover or the wrong cover from amazon. In this instance, you would be able to upload an image locally, or force that bib to use a different service for it's book cover.
So, rather than requiring you to add covers to each bib by hand, you could cascade through different cover options. Check for local image first, if not found, use amazon.
Does that sound like a good idea?
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 6:31 PM, Reed Wade <reedwade@gmail.com> wrote:
Selecting and storing images locally for all holdings sounds like a pain.
I can imagine a cooperatively held db (hello, koha foundation) of records that look like:
isbn/issn/other globally unique id that identifies the holding in a way that makes searches possible url to images (front, back, etc) - maybe they're on flickr, or in amazon land image license and/or attribution statement caching limits who updated when updated
And some simple REST style api that allowed a module to display the attribution and use the image url directly for display or via a (potentially caching) proxy for local library networks that might require it.
And a mechanism for adding/updating records to the cooperatively held db. And for automatically using them maybe based on who updated them in case some folks turn out to be bad at it.
A variation -- instead the central db providing the look up service. It could provide just the collective DB with your local koha instance subscribing to updates. So, the user load of the lookup is local but we get the benefit of sharing the effort of selecting images. (Reinvention of usenet data flow architecture sort of.)
-reed
On Fri, Sep 18, 2009 at 5:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Excellent ideas all around. I suppose it could be written as a CPAN module which would then be used in Koha.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Thu, Sep 17, 2009 at 1:05 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Sep 17, 2009 at 12:04 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This new Covers module would be the sole interface for Koha for all cover systems ( Amazon, LibraryThing, Syndetics, etc. ) and would act as an interface between Koha and the book cover modules.
Good idea. It occurs to me that this could be *very* loosely coupled to Koha and done as a component that could be used by other applications, as all that it would need from Koha itself are some configuration settings and some information from each bib record to grab covers for.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/RFC%3A-Koha-Book-Cover-System-tp25494328p25508019.html Sent from the Koha - Dev mailing list archive at Nabble.com.
Hmm...being able to select a local "cover" would also be useful for non-print items for loan, such as toys, equipment, etc. :) Cheers, Cindy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org David Schuster wrote:
This is a great idea. I personally don't care that much about the "service" in which my jacket comes from but the idea of being able to get a picture of the cover if one isn't available. We have several items that are "unique" that we would love to have jackets of but are not part of the general trade binding. It is very helpful to the teachers when you say to them - "This is what it looks like" and they say "oh the one with the purple cover!"
Of course how you obtain that jacket to store is another issue dealing with copyright etc... But hopefully librarians get that and do the right thing.
participants (8)
-
Cindy Murdock Ames -
David Schuster -
Galen Charlton -
Joe Atzberger -
Kyle Hall -
Michael Hafen -
Reed Wade -
Rosalie Blake