KJk46VC2Y3bwCdFAzl6Nfpg5kNOAnIS+UZFII3
3dsAn3luo4pUlbGAqFZaoIE9P2N3vgXC
=6MFU
-----END PGP SIGNATURE-
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
smime.p7s
Description: S/MIME Cryptographic Signature
l: 510.987.0832
Email: dana.jemi...@ucop.edu
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
How can you not fall in love?
-- Susan
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
mendations.
Desired features include the following:
- 2 factor authentication
- The ability to define groups or teams, and assign specific credential
sets to those groups
- The ability to revoke access
- Hosted services are a plus
Thanks,
Mark
--
Scott Prater
Shared Development Group
General Libr
ice with php or python or whatever. Does such a resource exist? Any
advice on where to start?
Thanks,
Mike Beccaria
Systems Librarian
Head of Digital Initiative
Paul Smith's College
518.327.6376
mbecca...@paulsmiths.edu
Become a friend of Paul Smith's Library on Facebook today!
-
anization with the time or authority
to act as editorial overseer. What are some techniques for ensuring that
the site maintains a clean, professional appearance?
Give up and let chaos reign supreme?
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In prac
searchable by ISBN.
Bonus is if they have good clean graphic design.
Extra bonus is if they manage to include shipping prices in their
price comparisons.
Thanks!
Jonathan
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415
browser now, thanks largely to competition from Firefox and Chrome. If
coming up with a viable alternative to EZproxy using open source tools causes a
security, features, and functionality arms race, then everyone wins.
--
Scott Prater
Shared Development Group
General Library System
University of
externally. This may not be a real issue, as many academic sites
> >already use LMS or portal systems instead of the EZproxy to direct students
> >to resources, so this feature may not be as critical to replicate.
> >
> >- And of course, extensive testing. While the above ProQuest stanza works
> >for the main ProQuest search interface, it won’t work for everyone,
> >everywhere just yet.
> >
> >Bottom line: Yes, Apache HTTPd is a viable EZproxy alternative if you have a
> >system administrator who knows their way around Apache HTTPd, and are
> >willing to spend some time getting to know your vendor services intimately.
> >
> >All of this testing was done on Fedora 19 for the 2.4 version of HTTPd,
> >which should be available in RHEL7/CentOS7 soon, so about the time that hard
> >decisions are to be made regarding EZproxy vs something else, that something
> >else may very well be Apache HTTPd with vendor-specific configuration files.
> >
>
>
> --
> Stuart Yeates
> Library Technology Services http://www.victoria.ac.nz/library/
--
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
ample please send it along either here on list or to me
directly.
Thanks!
//Ed
PS. sorry for the duplication.
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415
Thanks, Jonathan. We'll definitely check it out.
-- Scott
On 11/20/2013 12:13 PM, Jonathan Rochkind wrote:
On 11/20/13 12:51 PM, Scott Prater wrote:
I think the issue comes down to a distinction between a stream and a
record. Ideally, the ruby-marc library would keep pointers to
On 11/20/2013 11:18 AM, Jonathan Rochkind wrote:
On 11/20/13 11:40 AM, Scott Prater wrote:
I would suggest one or the other -- the default of leaving bad bytes in
your ruby strings is asking for trouble, and you probably don't want to
do it, but was made the default for backwards c
oes seem odd, doesn't it? To say something
should be default that hardly anyone hardly ever will want?
On 11/20/13 10:10 AM, Scott Prater wrote:
We run into this problem fairly regularly, and in fact, ran into it on
Monday with ruby-marc.
The way we've traditionally handled it is to put our
hich should be the default behavior, #1 or #2? If most people most
of the time are going to want #2 (is this true?), then should that be
the default behavior? Or should #1 still be the default behavior,
because by default bad input should raise, not be silently recovered
from, even though most peop
ion is for the first
location, the second accessCondition ois for the second loaction etc etc).
As I understand the order of elementents in MODS shouldn't matter.
2. Access conditions and embargo's are free-text!
Are there best practices we should use?
Greetings from Belgium
Patrick
15 matches
Mail list logo
