I recently posted some screenshots of the new web-based Fedora administrative GUI. Take a look here: Web Admin Screenshots
I just posted a mockup of how I'm thinking the new Administrator GUI may look/work. Take a look, and add a comment letting me know what you think.
Fedora 3.1 has been released!
Fedora 2.2.4 has been released!
WooHoo!
In other news, I'm working up a plan for an application called FedoraShare. This will be a front-end application for Fedora which integrates with content that is stored on other sites around the web and allows users to tag, comment on, and create relationships between any content, whether it be stored in Fedora or not. For more info, take a look at my write up and screenshot mockups.
Other than various activities surrounding the 3.1 release coming up next week, my main work of interest this week was doing a review of Open Laszlo and writing up my thoughts on Flex and Open Laszlo so far. The end goal of this investigation is to get started on a new web-based Administrator GUI for Fedora.
The first half of this week I spent with Chris at MIT sitting in on the DSpace 2.0 architecture design meeting. In this session, they were focused primarily on determining the high-level services necessary to support the next version of DSpace.
- One discussion which we returned to several times was the idea that there is fundamental set of services needed by any repository which could be constructed in a layered structure. Chris posted an initial write-up of these ideas.
- Another discussion that Chris and I had on the side with Richard Rodgers was that the notification capabilities of both Fedora and DSpace present a way to coordinate the content available in each system. An example of this could be to allow both Fedora and DSpace to store content in the same location (such as on Amazon S3), then use update notifications to create/update/delete the object model. This gets around the need to have a shared data model in order to share content.
The last half of the week was spent finishing up tasks prior to the 3.1 release.
- Completed and merged FCREPO-245, which allows GSearch (and any other user of the MessagingClient) to start up prior to the messaging provider being available. This was primarily an issue when Fedora and GSearch were running in the same server and GSearch was started first.
- Completed and started review of FCREPO-241, which provides authentication filtering for the REST API relative to the authentication settings of API-A and API-M.
Here's what I've been up to lately:
- As a presenter at the SPARC conference innovation fair, I was asked to post a graphic about my topic, which I've done here: SPARC Post. The idea is similar to FedoraShare, but using a conference organizer as an example.
- Worked on FCREPO-241 which is an issue with the REST API not correctly prompting for authentication. The REST API, up to this point, has not been included in the servlet filtering chain which allows other Fedora interfaces to authenticate users. With my updates there is now an additional filter which determines whether a REST API method is part of API-A or API-M, then passes the request along to the authentication filter if necessary. Some testing still needs to be done here, but my goal is to get this done in time for the 3.1 release.
- Talked with a couple folks at Northwestern University about a potential JCR interface implementation for Fedora which looks promising.
- Updated the SVN properties for all .bat and .sh files in trunk and GSearch. This should resolve the issue that has come up several times now of shell scripts having incorrect line terminators. This also closes FCREPO-219.
- Reviewed Eddie's work on FCREPO-215, FCREPO-223, and FCREPO-236.
- Reviewed Chris' work on FCREPO-239, FCREPO-227, and FCREPO-252.
- Finished up the migration of tasks from SourceForge to Jira. Since the SourceForge export file did not actually include all of the task information (and an issue request received no attention) I had to break down and write the code necessary to retrieve the missing bits from each task page on the SourceForge site. It did work out fine, however, so we are now moved completely over to Jira for issue tracking.
- Prepared a bit for meetings on Monday and Tuesday with DSpace since my time spent with DSpace so far has been limited.
Some thoughts about the last week or so...
- We're getting close to being done with the migration of trackers from SourceForge to JIRA. The last major item is to move the task items, which we use to indicate work that's actually in progress. I was able to convert the code Chris wrote to migrate the other trackers (bugs, refactorings, new feature requests) to create the Jelly script for importing the SF tasks into JIRA, but in the process of testing, discovered that the SF export file was incomplete. This activity is now waiting on a service request with SourceForge, which hopefully will be completed soon and we can finish up our move to JIRA.
- I started looking into Zotero as it is one of the items on the list of integrations for the innovation challenge. I focused mainly on how Fedora could be used to store the information collected by Zotero. Doing this on the client is not very practical, but with the upcoming server storage capabilities of Zotero 2.0, this becomes interesting. In discussions with Eddie he pointed out that he was focusing more on allowing Zotero to easily harvest content out of Fedora using unAPI, and he gave a good overview of that work in the architecture meeting.
- After a discussion in last week's architecture meeting, I updated the fedora-client.jar to include the version of the Fedora server with which it was released. So we now have a fedora-3.0-client.jar, or at least we will as soon as my changes go into trunk.
- Looking again at the messaging client and the changes made to allow GSearch (or any other application) to make asynchronous broker connections, I realized that there's still a use case for a synchronous connection. Since a synchronous connection is implied in the MessagingClient interface, that is still the default, but passing in a parameter to start() allows the client to return while the connection is still being negotiated.
- Moving toward the goal of having a web-based administrative client for Fedora (as well as the possibility of a hosted Fedora application) I've started to investigate web-based GUI frameworks. The first of those is Adobe's Flex. I was able to create a simple application that has some admin client-type features with a small amount of xml in a relatively short amount of time.
The capabilities to connect to REST or SOAP-based web services quickly is impressive. The drawbacks of requiring a Flash player and the development tool being a commercial product do dampen my enthusiasm a bit, but I was happy to find that applications can be built using only the open-source pieces of Flex. Of course, Open Laszlo is a completely open-source alternative to Flex, so that's next on my list to consider.
Early this week I wrote up an overview of Amazon's web services offerings and posted it here. This included information about Amazon S3, EC2, EBS, and a bit about SimpleDB and SQS as well as information regarding how Fedora has been integrated with these services thus far, and where we might consider going. Discussions with the team during the newly started architecture meeting helped add several ideas to the list. In conjunction with this, I also ran some simple tests with EC2 using instance storage, EBS, and S3 as storage behind Fedora to see how the various storage types compared performance-wise. It turned out that the best performance came from EBS, then instance storage, followed after a while by S3.
My other focus this week was around an issue that has come up a couple of times regarding the updater in GSearch. In the default installation scenario GSearch is installed into the same Tomcat as Fedora, and Fedora starts the message broker on startup. Unfortunately, if the Tomcat server happens to start GSearch first, it's not able to connect to the message broker. To get around this the Fedora messaging client (which is used by GSearch) now spawns a thread to do the connection and performs several retries if the first attempt is not successful. This allows GSearch to let Fedora start and get the broker going before connecting. As a side note, testing this out required using a separate Tomcat to run GSearch, so it verified the ability to run GSearch external to Fedora.
My main focus this week was getting an EC2 image set up which properly builds, installs, and starts a Fedora server on instance startup. Most of this work was server configuration and scripting. I started by recreating the image I made last week (which provides a checkout of trunk) with some updates. I used that as my base, then added scripting to grab and update the provided install.properties file, set up the environment, update the code, install Fedora, convert the demos using the current IP, and start the Fedora server. Adding that to the server startup provided the desired results. I can now start an instance with either a configA or configB properties file, then log in and run the system tests, which pass with no further setup.
I'm considering my initial pathfinding prototype complete at this stage since I believe the capabilities of EC2 have been well enough established. There are features that are lacking, such as the ability to choose a database other than the default and have that started and configured for you, and the ability to select the JVM version to use. Based on what I've done so far, though, these things can certainly be accomplished, it's just a matter of taking the time to do it. I'd like to use the architecture meeting on Tuesday to discuss where we plan to go with AWS.
I also spent some time investigating the Amazon EBS, just doing basic setup, mounting, moving from instance to instance, etc. There's not a lot to this, really, but it's something that we will very likely use in conjunction with EC2.