That's a good point Matt.
 
I suppose my opinion comes down on the side of architecture... but that's because our architecture differs from the community norm. Most code I want to put back into the community has to be essentially 'un-hacked' to commit, whilst that remains the case.
 
This project is my full time job until July at this stage and I'd prefer to start getting the architecture squared away and our mid-year go live would be on a stable community release. But that's a very biased opinion because it's completely oriented around our project timelines.
 
If (for the sake of argument) I put our (USQ) goals down as getting a public RC2 out the door for our mid-year launch this would be our feature list in the context of the roadmap and this thread:
 
In
* Spell check
* Stats gathering (Completed internally and evolving)
* Schema terminology change (with update script for old versions)
* Hand written SQL change (Completed internally)
* DB_DataObject portability (Completed internally)
* Make Oracle fake auto_inc through DB_DataObject (Half-Completed internally, I think I've nearly got it)
* Proxy/Web request object
 
 
 
Out (delayed, not cut)
* Installation package (unless someone else is doing it already)
* Web admin (no idea where Andrew is at with this, he may put it in)
* Investigate removing auto_inc (if needed)
* Investigate jQuery or similar AJAX library.
 
 
Those are just a few thoughts based on the responses I saw over the weekend. There are other things as well, like Bill's feedback on the newer solr version giving performance boosts. You'll note I put some architecture changes in there (mostly the things we've already done) and put off the more experimental ones.
 

Greg Pendlebury
Electronic Services Officer (Systems Team)
Division of Academic Information Services
University of Southern Queensland
Phone: +61 7 4631 1501
Fax: +61 7 4631 1841

 


From: Matthew Hooper [mailto:Matthew.Hooper@flinders.edu.au]
Sent: Monday, 20 April 2009 12:09 PM
To: vufind-tech@lists.sourceforge.net
Subject: Re: [VuFind-Tech] VuFind: Long Term Direction

A solid v 1.0 release would also be nice... :-)  http://www.vufind.org/roadmap.php

(sort of reminds me of the long and tortuous wait for Firefox 1.0 – was it called Phoenix or Firebird then – I can’t remember, it was that long ago). How many releases did it take to finally get to 1.0?

 

I guess what I’m trying to say is that it would be nice to get a version one out the door with the basics working, and then mess around with what software bits run underneath and implement any goodies once it’s stable.

Where is vufind at now anyway, in terms of the roadmap for a 1.0 release? Is it time for a release candidate 2 – or has there been another architecture rewrite, and the code base needs some work to settle down?

We’re on 0.8 at the moment as a beta test, and probably won’t upgrade until the next code rollup since we’ll have to index all our records again and re-customize the interface, and I’m not too sure that rc1 is the release we want to go public with.

The effort is definitely appreciated though.

 

Cheers,

 

                Matt.

 

 

 

--
Matthew Hooper
Systems Officer,
Flinders University Library
G.P.O. Box 2100
ADELAIDE, South Australia 5001
( +618 8201 2068
7  +618 8201 2508
* Matthew.Hooper@flinders.edu.au

From: Greg Pendlebury [mailto:pendlebu@usq.edu.au]
Sent: Thursday, 16 April 2009 4:05 PM
To: 'vufind-tech@lists.sourceforge.net'
Subject: [VuFind-Tech] VuFind: Long Term Direction

 

Hi All,

 

Forgive me for the long email :)

 

Now that our site is in beta I've been looking in greater detail at the annoying little features we've put off until now. Andrew has also given me developer access to the svn and USQ is keen to contribute code back into the community if we are working on it.

 

With that in mind, I'd like to ask peoples opinions on three key areas we are looking at changing locally, and whether they have a place in the community code:

 

===============

1) Database Abstraction.

At the moment I've seen PDO in use inside the Voyager driver. But I believe that's the only place I've seen it. We replaced it with oci8 for our own driver, but I don't think it really matters what is used at that level... so no biggy.

 

The bigger issue for us has been getting the MyResearch area using DB_DataObject to play nicely with Oracle. We've had a few portability issues, but mainly lots of issues with auto incrementing indexes, a schema that uses several Oracle reserved words and mysql specific queries.

 

So the main points here are:

 

1A) Should we move the MyResearch schema to a portable terminology? For example, prefix all tables with 'vufind_' and all columns with a short abbreviation of the table name. So "resource.id" would become "vufind_resource.res_id".

 

1B) I'd like to update several of the hand written sql queries so that they will run under both mysql and oracle. Not a big deal, and I don't think anyone will object to this. Of course if anyone with knowledge of other DBMS idiosyncrasies would be welcome to help us ensure they are portable to that as well.

 

1C) I've got a couple of lines of code to add in so that we turn on oracle portability flags based on a conf file change : "[Database] is_oracle = 1". Would this be better as "[Database] dbms = oracle"? We can add extra functionality to that code later then. Is there an even better way to turn on portability? I couldn't seem to get it working within the conf file.

 

1D) auto_increment... I hates it :) In part I know the problem will be DB_DataObject is new to me. The doco says that the abstraction layer is supposed to be able to fake auto_increments inside Oracle, but I couldn't get it working. I'd be happy to work towards this working if someone things it should. For now we are doing stuff like this to avoid null values:

            $resource->insert();

            // Oracle's triggers to fake auto_inc

            //  cause problems if you don't do this

            $resource->id = null;

            $resource->find(true);

 

So if it can't be fixed we either need this somewhat ugly code throughout the app or move away from auto_inc altogether. Opinions?

 

1E) Bind variables... I haven't seen much if any information on this for DB_DataObject, does it even support them? It would be very disappointing if it didn't. Personally I'd even consider a wholesale move to something like PDO if it didn't. The effect they have on Oracle's cache can be significant for a small schema with high turnover.

 

 

===============

2) AJAX... jQuery

 

AJAX is quite new to me, so it's been interesting debugging some of the issues in the MyResearch area, especially following Chris' code for add tags on the record screen (very good by the way, I used it to fix the comments tab). One of the little issues I ran into was the problem of returning javascript code into the lightbox on those screens, because you can't just call the resultant code. When reading some forum posts about similar issues I here you have to regex and eval the script out before they work... unless you use jQuery or some similar library.

 

Being a novice on the issue does implementing jQuery sound like a good way to simplify the AJAX usage in vufind? I want to look into it more myself, but if there are any other users our there with experience I'd live to hear you opinion.

 

 

===============

3) External web requests

 

I'm going to create a global object in our codebase for making external web requests. Our server lives behind a firewall and needs to proxy it's way out and I've found quite a few locations I need to go and set that proxy information. I figure it's an easier way of tying the proxy information to the config files. I don't think this is 'key' area really, but if you don't want that code back in the community please let me know, because I'd like to put it there.

 

 

===============

No doubt there are other smaller issues that we'll contribute code for as well, but I'll annoy you all in separate emails for those :)

 

 

Ta,

 

Greg Pendlebury

Electronic Services Officer (Systems Team)

Division of Academic Information Services

University of Southern Queensland

Phone: +61 7 4631 1501

Fax: +61 7 4631 1841

 

 


This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW 02225M)


This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW 02225M)