[index] [prev] [next] [options] [help]
See the Mailing Lists Page for how to subscribe and unsubscribe.

eprints_tech messages

Please note: this page shows emails that have been sent to the eprints_tech mailing list. Some of these may be spam emails we have failed to filter.

Re: [EP-tech] Problems with OO Design

From: ePrints Support <support AT eprints.org>
Date: Fri, 23 Mar 2001 16:55:03 +0000

Threading:

↑ [EP-tech] Problems with OO Design from crcarter AT cs.indiana.edu
• This Message


Enough already :-)

I've set up a nightly script which knocks together a tar file of 
the code. This is available from http://www.ecs.soton.ac.uk/~cjg/eprints/

For those of you not familiar with development code, don't be surprised
if it (A) dosn't work and (B) isn't quite as well commented as the release
version...



On Fri, Mar 23, 2001 at 02:39:10PM -0000, Tim Brody wrote:
> > I would like to make a read-only version of the CVS available at some
> > point but at the moment there's a lot of 'scaffold' to make things ↵
work
> > as I rewrite various sections. I'd spend all my time helping people
> > get it working.
> 
> Awww ... you just want to keep it to yourself don't you?
> 
> Seriously, does it really matter? After all, compiling from CVS is only ↵
for
> developers, if you want a working system you should download a release
> version...
> 
> (One of the reasons I've not got around to looking at ePrint internals is
> because it would involve downloading/installing, source code access via ↵
CVS
> obviates that need)
> 
> Regards,
> Tim.

-- 

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

Re: [EP-tech] Problems with OO Design

From: Clayton Carter <crcarter AT cs.indiana.edu>
Date: Mon, 26 Mar 2001 15:10:59 -0500

Threading:

↑ [EP-tech] Problems with OO Design from crcarter AT cs.indiana.edu
• This Message


	This is good to hear.  The more I learn about the next
release, the more excited I get about it.  Who ever said serious
software can't be cool?  :)

--pc

On Fri, Mar 23, 2001 at 12:41:58PM +0000, ePrints Support wrote:
> Although under normal circumstances, I'd take a patch and say thankyou,
> the current development version of EPrints looks VERY different.
> 
> I've been slowly phasing out variables like the one you mention below, 
> I'll make even more of an effort now.
> 
> I would like to make a read-only version of the CVS available at some
> point but at the moment there's a lot of 'scaffold' to make things work
> as I rewrite various sections. I'd spend all my time helping people
> get it working.
> 
> One neat little change is that it will load all the modules when apache
> starts, NOT each time it spawns a sub process.
> 
> Also SiteInfo, SiteRoutine etc are going to be rolled into one module,
> which will be named after the id of your site eg.
> EPrintSite/cogprints.pm
> 
> This module will provide an object which will represent the site ↵
configuration
> including references to methods for validation, rendering etc.
> 
> It decides what config module to load based on the host and path of the ↵
URL
> request and does some reflection, which perl is good at.
> 
> 
> On Thu, Mar 22, 2001 at 03:26:10PM -0500, Clayton Carter wrote:
> 

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

[EP-tech] Slowly but surely

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

[EP-tech] Other little things...

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

[EP-tech] problems

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

Threading:

• This Message
→ Re: [EP-tech] problems from crcarter AT cs.indiana.edu


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.

Re: [EP-tech] problems

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

Threading:

↑ [EP-tech] problems from imdad_md AT hotmail.com
• This Message


	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."

[EP-tech] eprints

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

Threading:

      • This Message
            → Re: [EP-tech] eprints from cjg AT ecs.soton.ac.uk
            → Re: [EP-tech] eprints from stephen.thomas AT adelaide.edu.au
            → [EP-tech] Eprints from marco.merli AT unife.it


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

Re: [EP-tech] eprints

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

Threading:

↑ [EP-tech] eprints from Mark.Faine AT msfc.nasa.gov
• This Message

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)

Re: [EP-tech] eprints

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

Threading:

↑ [EP-tech] eprints from Mark.Faine AT msfc.nasa.gov
      • This Message
            → Re: [EP-tech] eprints from tdb198 AT ecs.soton.ac.uk
            → Re: [EP-tech] Eprints from tajoli AT cilea.it

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.

Re: [EP-tech] eprints

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

Threading:

↑ Re: [EP-tech] eprints from stephen.thomas AT adelaide.edu.au
• This Message

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

Re: [EP-tech] eprints (buggy?)

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

Threading:

• This Message
→ Re: [EP-tech] eprints (buggy?) from crcarter AT cs.indiana.edu


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

[EP-tech] database creation

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

Threading:

• This Message
→ Re: [EP-tech] database creation from cjg AT ecs.soton.ac.uk


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

[EP-tech] Questions on use

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

Threading:

      • This Message
            → Re: [EP-tech] Questions on use from cjg AT ecs.soton.ac.uk
            → Re: [EP-tech] Questions on use from cjg AT ecs.soton.ac.uk

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!

[index] [prev] [next] [options] [help]

Tech List

eprints_tech messages

Re: [EP-tech] Problems with OO Design

Re: [EP-tech] Problems with OO Design

[EP-tech] Slowly but surely

[EP-tech] Other little things...

[EP-tech] problems

Re: [EP-tech] problems

[EP-tech] eprints

Re: [EP-tech] eprints

Re: [EP-tech] eprints

Re: [EP-tech] eprints

Re: [EP-tech] eprints (buggy?)

[EP-tech] database creation

[EP-tech] Questions on use