eprints_tech messages

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Fri, 11 May 2001 07:10:34 -0500

Seems from I can tell that Linux installs work best.  

Is eprints the only OAI software available?

-Mark

-----Original Message-----
From: Clayton Carter [mailto:crcarter AT cs.indiana.edu]
Sent: Thursday, May 10, 2001 3:14 PM
To: EPrints.org Technical List
Subject: Re: [EP-tech] eprints (buggy?)


	I wouldn't go this far, but I will say that I didn't have too
much trouble with the install.  I had to work some voodoo so that the
Debian installed Perl modules would co-exist with the newer versions
from CPAN.  Also, I had never used MySQL before, so that was an
adventure; but overall, I didn't have too much trouble.  I'm not
saying it's easy or that it's done well, mind y'all, I'm just saying
that installed it without major problems.

	What I will say is that the system is a bitch to develop for.
Whoever developed this code was living in some strange fantasy world.
A lot of it is done very well and quite cleverly, but the rest is
bizarre and can only be described by a big bowl of extra sloppy
linguine.  But it works, so make of it what you will.

--pc


On Wed, May 09, 2001 at 10:24:26AM +0000, Dan Fleming wrote:
> Buggy eh?
> 
> Eprints is a breeze to install on Linux. I set it up on Red Hat 7 where I 
> guess I had the benefit of Red Hat's quck & easy installation methods ↵
for 
> locating and setting up all the prerequisite stuff. I used to use Solaris
and 
> imagine it would have been a lot harder getting that sorted out prior to 
> installing eprints. I know Chistopher says negative feedback is more
useful 
> than positive, but I just thought I'd offer this encouragement to anyone
who 
> wants to set it up on Red Hat and might otherwise be put off.
> 
> Dan
> 
> Dr D Fleming
> University of Ulster

-- 
Clayton Carter   crcarter AT cs.indiana.edu
"My mom says I'm the handsomest guy in school."

From: Clayton Carter <crcarter AT cs.indiana.edu>
Date: Thu, 10 May 2001 15:13:31 -0500

	I wouldn't go this far, but I will say that I didn't have too
much trouble with the install.  I had to work some voodoo so that the
Debian installed Perl modules would co-exist with the newer versions
from CPAN.  Also, I had never used MySQL before, so that was an
adventure; but overall, I didn't have too much trouble.  I'm not
saying it's easy or that it's done well, mind y'all, I'm just saying
that installed it without major problems.

	What I will say is that the system is a bitch to develop for.
Whoever developed this code was living in some strange fantasy world.
A lot of it is done very well and quite cleverly, but the rest is
bizarre and can only be described by a big bowl of extra sloppy
linguine.  But it works, so make of it what you will.

--pc


On Wed, May 09, 2001 at 10:24:26AM +0000, Dan Fleming wrote:
> Buggy eh?
> 
> Eprints is a breeze to install on Linux. I set it up on Red Hat 7 where I 
> guess I had the benefit of Red Hat's quck & easy installation methods ↵
for 
> locating and setting up all the prerequisite stuff. I used to use Solaris ↵
and 
> imagine it would have been a lot harder getting that sorted out prior to 
> installing eprints. I know Chistopher says negative feedback is more ↵
useful 
> than positive, but I just thought I'd offer this encouragement to anyone ↵
who 
> wants to set it up on Red Hat and might otherwise be put off.
> 
> Dan
> 
> Dr D Fleming
> University of Ulster

-- 
Clayton Carter   crcarter AT cs.indiana.edu
"My mom says I'm the handsomest guy in school."

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Thu, 10 May 2001 07:33:26 -0500

    Ok, I've noticed there are several different upload types and an
arbirtrary flag. If you were building from the ground up a new system
wouldn't it be best to provide an interface for that system that allowed new
reports to be inputted to the system directly and converted to XML to be
stored on the archive server as XML.  Then when the user searched for a
record it could be displayed in any number of formats using XSL or CSS.
Before I started digging into the functionality of eprints, I thought that
was how it worked.  
 
-Mark

_____________________________________ 

Mark Faine 
Computer Programmer III/MTRS Administration 
Lesco/MSFC 
256-961-1295 

 

--

ATTACHMENT: eprints-tech.22.2.html!
--

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Wed, 9 May 2001 12:58:20 -0500

Ok, I've gottent the apache with mod_perl operational and all is good on the
web server front.

I decided earlier to re-install manually the eprints software. I'm to the
point where I need to 
run scripts that update/create the database, specificaly the cron tab
scripts but really none of the scripts will work.

I just get somehting like:

[root AT trs]296[/usr/local/apache/eprints/bin]# ./subs_daily 
DBI->connect(database=eprints) failed: Access denied for user:
'eprints AT localhost' (Using password: YES) at
/usr/local/apache/eprints/perl_lib/EPrints/Database.pm line 134
TRS has encountered an error:

Failed to connect to database

Can't call method "retrieve_fields" on an undefined value at
/usr/local/apache/eprints/perl_lib/EPrints/Subscription.pm line 338.

-------------------------------------------------------------------

I would like to change the username the scripts are using to "nobody" ↵
but I
can't figure out how, except a direct hack on the Database.pm file, and I've
tried, nobody can't connect either.   $EPrintSite::SiteInfo::username is set
to "nobody" but still it tries to connect as eprints.

I know the grants and users are set up right because I can connect as nobody
or eprints from the command line.


Basically if I get through this database problem that should be the last
hurdle to clear as that is the only thing holding back a completed
installation at this point.

Any help would be appreciated?

-Mark



_____________________________________ 
Mark Faine 
Computer Programmer III/MTRS Administration 
Lesco/MSFC 
256-961-1295 

From: "Dan Fleming" <DR.Fleming AT ulst.ac.uk>
Date: Wed, 9 May 2001 10:24:26 GMT

Buggy eh?

Eprints is a breeze to install on Linux. I set it up on Red Hat 7 where I 
guess I had the benefit of Red Hat's quck & easy installation methods for 
locating and setting up all the prerequisite stuff. I used to use Solaris and 
imagine it would have been a lot harder getting that sorted out prior to 
installing eprints. I know Chistopher says negative feedback is more useful 
than positive, but I just thought I'd offer this encouragement to anyone who 
wants to set it up on Red Hat and might otherwise be put off.

Dan

Dr D Fleming
University of Ulster

From: Tim Brody <tdb198 AT ecs.soton.ac.uk>
Date: Wed, 9 May 2001 10:00:42 +0100 (BST)

On Wed, 9 May 2001, Steve Thomas wrote:

> Christopher Gutteridge wrote:
> > 
> > Hi. Thanks for the feedback :)
> > 
> > The problem with eprints 1.1 is that there is a lot of supporting ↵
software
> > required. I'd like to point out that it's not buggy, a bitch to ↵
install, but
> > not buggy.
> 
> FWIW, I never even got as far as installing the actual eprint
> software. I tried following the instructions regarding all the
> additional and prerequisite bits of software, but couldn't even
> get that far. Basically, I got stuck with the install of the
> Msql-MySQL-modules -- the install failed because it needed
> something from MySQL which wasn't there.

Firstly I haven't ever tried to install e-prints (I didn't get beyond the
"Oh this doesn't have a "click-here" installer..."), but I ↵
may be able to
suggest some help regarding MySQL:

Having had a little bit of experience with getting the MySQL PERL modules
working, if you want to compile from source you'll probably need the MySQL
source distribution, not just the binary, to link against.

Alternatively you could try experimenting with using PERL to install
these? (I know ActivePerl under windows uses its own package management to
install MySQL modules, which works very well)

Alternatively ...
Having taken a look at the package list for Red Hat 7.1, I believe it
includes MySQL and the PERL MySQL libraries.
As PERL uses standard locations for libraries, I would guess that an
install of R/h 7.1 should provide all the ancillary database programs
(I don't know about the Apache server requirements)

> Now, I'll confess to being only a novice-level Linux sysadmin,
> but I've generally been able to install, configure and run all
> kinds of software on a variety of unix platforms without too
> much drama. But this defeated me entirely.

> All of which leads me to suggest that, while the concept of the
> eprint server is wonderful, and received much applause at this
> year's Information Online conference in Sydney, I think that
> growth in eprint servers is going to be very slow until someone
> smarter than me can put it all together in a neater,
> easy-to-install package.
> 
> Admins like me need "eprint-in-a-box". Please?

Agreed, perhaps a static version of eprints could be built that includes
all the necessary software ... item # 2004 todo Chris?

All the best,
Tim Brody

From: Steve Thomas <stephen.thomas AT adelaide.edu.au>
Date: Wed, 09 May 2001 09:38:42 +0930

Christopher Gutteridge wrote:
> 
> Hi. Thanks for the feedback :)
> 
> The problem with eprints 1.1 is that there is a lot of supporting software
> required. I'd like to point out that it's not buggy, a bitch to install, ↵
but
> not buggy.

Yes, installation was a problem for me -- to the point where,
unfortunately, I had to shelve the idea of an eprint server.

FWIW, I never even got as far as installing the actual eprint
software. I tried following the instructions regarding all the
additional and prerequisite bits of software, but couldn't even
get that far. Basically, I got stuck with the install of the
Msql-MySQL-modules -- the install failed because it needed
something from MySQL which wasn't there.

Now, I'll confess to being only a novice-level Linux sysadmin,
but I've generally been able to install, configure and run all
kinds of software on a variety of unix platforms without too
much drama. But this defeated me entirely.

All of which leads me to suggest that, while the concept of the
eprint server is wonderful, and received much applause at this
year's Information Online conference in Sydney, I think that
growth in eprint servers is going to be very slow until someone
smarter than me can put it all together in a neater,
easy-to-install package.

Admins like me need "eprint-in-a-box". Please?


Regards,

Steve

--
Stephen Thomas, 
Senior Systems Analyst, 
Adelaide University Library
ADELAIDE UNIVERSITY SA 5005
AUSTRALIA
Tel: +61 8 8303 5190  Fax: +61 8 8303 4369
Email: stephen.thomas AT adelaide.edu.au 
URL: http://www.library.adelaide.edu.au/~sthomas/

----------------------------------------------------------- 
This email message is intended only for the addressee(s) 
and contains information which may be confidential and/or
copyright.  If you are not the intended recipient please
do not read, save, forward, disclose, or copy the contents
of this email. If this email has been sent to you in error,
please notify the sender by reply email and delete this 
email and any copies or links to this email completely and
immediately from your system.  No representation is made
that this email is free of viruses.  Virus scanning is 
recommended and is the responsibility of the recipient.

From: Christopher Gutteridge <cjg AT ecs.soton.ac.uk>
Date: Tue, 8 May 2001 21:59:37 +0100

Hi. Thanks for the feedback :)

The problem with eprints 1.1 is that there is a lot of supporting software
required. I'd like to point out that it's not buggy, a bitch to install, but
not buggy.

If I had a team of experts or an extra 8 hours a day, I'd produce a 
script to run on a fresh redhat linux install which would install everything
you need. However, I must sleep.

Negative feedback is actually more helpful than positive, so feel free to
send a detailed report to support AT eprints.org - you can't hurt my feelings
as I only took over the software at v1.0 to 1.1 

Also, this is free software - for the general good, cus people can use it,
rather than to make money or stuff. So if someone on the tech list has the
time and inclination, there's no reason you couldn't write a comprehensive 
install how to which I can put on the site. 

On Tue, May 08, 2001 at 03:24:59PM -0500, Faine, Mark wrote:
> Ok, First I must give thanks for the eprints software, you are doing a ↵
good
> thing.  Now that I have made it clear that I do appreciate your work I ↵
have
> to say this is the absolute buggiest piece of software I've ever seen for
> Unix.  (and I've seen a lot) I'm fairly competent with these things and ↵
I've
> been instaling this software for two and a half days now.
> 
> I would list the problems I'm coming up with but they are far too ↵
numerous.
> 
> 
> Just to let you see this message isn't all negative, I have a suggestion,
> how about one really good step by step "bulletproof" ↵
comprehensive set of
> steps necessary to install this software without a hitch.  Including all
> related dependent software in the order in which it needs to be installed.
> 
> I say it might be better to include all that software as part of the
> distribution where licenses will allow it.
> 
> 
> Thanks,
> 
> -Mark

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
The Moabites and 22,000 Syrians (II Samuel 8:2, 5, 6, 14) 

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Tue, 8 May 2001 15:24:59 -0500

Ok, First I must give thanks for the eprints software, you are doing a good
thing.  Now that I have made it clear that I do appreciate your work I have
to say this is the absolute buggiest piece of software I've ever seen for
Unix.  (and I've seen a lot) I'm fairly competent with these things and I've
been instaling this software for two and a half days now.

I would list the problems I'm coming up with but they are far too numerous.


Just to let you see this message isn't all negative, I have a suggestion,
how about one really good step by step "bulletproof" comprehensive ↵
set of
steps necessary to install this software without a hitch.  Including all
related dependent software in the order in which it needs to be installed.

I say it might be better to include all that software as part of the
distribution where licenses will allow it.


Thanks,

-Mark

From: Clayton Carter <crcarter AT cs.indiana.edu>
Date: Fri, 27 Apr 2001 15:33:23 -0500

	I just reread your message and I think I have a solution.  If
you just want to display the name of the subject category this
document belongs to, you can use something like this:

my  AT subjects = split /:/, $eprint->{subjects};
foreach my $subject ( AT subjects) {
    print EPrints::Subject::subject_label( $session, $subject ) . ↵
"<BR>";
}

	Like I said, if you just want to include the subject
information in some page.  If you want to search for EPrints based on
the subject category they're in, see me old reply (listed below).

	Also, if you change the system metadata in the Perl modules,
you might have to redo the `create_databases' command inorder for the
changes to take effect.  I don't know if that's true it'd make sense.

	Hope that helps.

--pc


[=== begin old reply ===]

	We've accomplished this by adding a hidden field to all of the
document types in cfg/metadata.eprint-types and then modifying
update_from_subject_form in SubmissionForm.pm with something like
this:

my $subjecttext = "";
foreach my $subject ( AT subjects) {
    # subject_label takes a session and a subject key and returns
    # the full subject hierarchy associated with that key.
    # Please note the " " dotted onto the end of returned string.
    $subjecttext .= 
        EPrints::Subject::subject_label( $self->{eprint}->{session},
					 $subject ) . " ";
}
# Finally, we'll commit the changes to actual subjecttext field
$self->{eprint}->{subjecttext} = $subjecttext;

	where `subjecttext' is the name of field added in
metadata.eprint-types.  I don't know if this is exactly what you're
looking for, but we did it so that we could not only search explictly
in one subject (which was provided on the advanced search page) but
also for substrings of the subjects.  (ie - We could either select
`East Asia' from the subject list on the advaced search page, or we
can enter `Asia' on the simple search and retrieve results in `East
Asia' and `Middle East & South Asia'.

	Hope that helps.

--pc

[=== end old reply ===]

On Tue, Apr 24, 2001 at 02:14:00PM +0000, mohamed imdadullah wrote:
> Hi everybody
> 
> I am a student and i have been trying to modify the eprints archive to ↵
have 
> my own small library on the net.
> 
> I have been able to replace the metadata in the cofiguration files and ↵
have 
> a working eprint archive and iam very happy about that.
> 
> I wanted to add another metadata field in System_meta_fields of the 
> Eprint.pm class so that i could read the subject name apart from the 
> subjectid in  subject.pm class. I have been trying to find out where to ↵
make 
> the required modification and havent been quite successful.
> 
> When i just include the new metadata in the system_meta_fields of the 
> EPrint.pm, i see that the bibiliographic information page in the ↵
depositing 
> section is not represented and it doesnt give me an error message too.
> 
> I am new to PERL and i would be delighted if someone could help or ↵
clarify.
> 
> regards
> mhd
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

-- 
Clayton Carter   crcarter AT cs.indiana.edu
"My mom says I'm the handsomest guy in school."

From: "mohamed imdadullah" <imdad_md AT hotmail.com>
Date: Tue, 24 Apr 2001 14:14:00

Hi everybody

I am a student and i have been trying to modify the eprints archive to have 
my own small library on the net.

I have been able to replace the metadata in the cofiguration files and have 
a working eprint archive and iam very happy about that.

I wanted to add another metadata field in System_meta_fields of the 
Eprint.pm class so that i could read the subject name apart from the 
subjectid in  subject.pm class. I have been trying to find out where to make 
the required modification and havent been quite successful.

When i just include the new metadata in the system_meta_fields of the 
EPrint.pm, i see that the bibiliographic information page in the depositing 
section is not represented and it doesnt give me an error message too.

I am new to PERL and i would be delighted if someone could help or clarify.

regards
mhd
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From: ePrints Support <support AT eprints.org>
Date: Mon, 9 Apr 2001 10:45:29 +0100

I've decided to explicitly support ISO-LATIN-1, I know that OAI uses
UTF8 but if I don't limit my scope of features I'll never finish.

I'm thinking of redesigning the web-based registration. Well in fact, I'm 
going to, but I'm thinking about how.

I'm thinking of having a page which asks you to enter your email, the system
then generates a random password for that email, sets the username to 
be the SAME as the email and mails that person their password. This will
close the can of worms which is the process_mail script, which I think has
been the single biggest support problem.

This also adds the neat feature, that if you have "local" and ↵
"signup"
users, eg. members of your dept. and just random people off the web, then
you know that the "signup" users, will have an " AT " in ↵
their username which
means you can never have a problem I've been worried about which is:

Our department allocates usernames to it's users, we want them to be able
to use the same username/password as for email and logins.

Problem: If someone signs up on the web for a username which is free, but 
then the dept. admin allocate that username internally 3 months later - not
to be able to give a member of our dept. a username because someone on the
eprints system is already using it is a case of the Tail wagging the dog.

Hence the email address solution above is a nice solution. This dons't mean
local users couldn't all log in via email address too - email addresses have
the nice feature of being unique (well, most of the time).


I'm toying with removing process_mail from the next minor release of eprints1.1
as it's causing a lot of pain - I would make the "username" requested ↵
be
the email address minus everything after the " AT ".

Would people think that this is great or the work of the devil?

For a demonstration of how this system would work, the following web ↵
"service"
has been running for some time without serious problem, feel free to "poke ↵
it"
if you want to how the web based signup would work (ish): 
http://totl.net/VCash/




-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833

From: ePrints Support <support AT eprints.org>
Date: Mon, 9 Apr 2001 10:32:03 +0100

Latest things I've been working on:

XHTML, stylesheets & DOM.

I've been changing the internals of eprints so that rather than generating
a webpage by doing:

print "<P>"; 
print "My Cat";
print "</P>"

The system now builds the entire page as an xml tree then prints it:

use XML::DOM;
$page = new XML::DOM::Document;
$p = $page->createElement( "p" );
$cat = $page->createText( "My Cat" );
$p->appendChild( $cat );
$page->appendChild( $p );

OK, that dosn't produce a legal page (no <html> etc) but you get the ↵
idea.

XHTML is, in a nutshell HTML represented in XML (which can still be parsed
by current browsers). The practical differences are that all element and 
attribute names must be lower case, and that ALL elements must be closed. Eg.
<BR></BR>
which can be abbv'd. to:
<BR />

The template for pages in the config module must be in xhtml, as the system
parses it into a tree when it starts up (not every page request).

This is slightly harder, but means that the system will always produce 
well formed pages. Which is nice.

I've been removing as much markup as I can from the HTML (XHTML now!) produced
by eprints, and replacing it with class="foo" attributes to each ↵
part, so that
the admin can control the look of the generated pages without having to hack
at the code.

I've changed the way "citation configuration" works - this is the way ↵
in which
a record is rendered into a single string, for search result pages etc.

The new system is, shock!, XML - or more accurately an XHTML fragment with
two extra elements: <IF> and <FIELD> (note these *are* uppercase so ↵
they
are clearly distinct from the XHTML elements.

Eg. for conf paper:

<FIELD name="authors"/> <IF ↵
name="year">(<FIELD name="year"/>) 
</IF><FIELD name="title"/>. In <IF ↵
name="editors"><FIELD name="editors"/>, 
Eds. </IF><IF name="conference"><i>Proceedings 
<FIELD name="conference" /></i></IF><IF ↵
name="volume"> 
<b><FIELD name="volume" /></b></IF><IF ↵
name="number">
(<FIELD name="number" />)</IF><IF ↵
name="pages">, pages <FIELD name="pages" />
</IF><IF name="confloc">, <FIELD ↵
name="confloc" /></IF>.

I know this is more verbose but it allows control of exactly what you want
rather than the old system which was yet another config system.

When rendering the system first removes all <IF> elements, leaving their
contents behind IF the named field is not empty in this record, then the
system replaces <FIELD> tags with the value of the named field.

I'm considering doing something similar with the language configuration files,
using XML.

-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833