VinylCat Update: Let’s Get This Show on the Road!
Alright, well I’ve been mulling over this one for a while and I think I’ve got a few basic things worked out… though they are subject to change.
I’ve decided to have VinylCat work in two parts: server side, and client side. The reason behind this is that if everyone used just their own client-side application to enter in their releases, they would have to type out the info for every release in order to add their collection to their catalog; this just doesn’t make any sense since many people have the same records, and records all have the same information.
The server-side will run wiki-pedia style so that all registered users and edit all information available (this is the one part that I’m still unsure about). This way, on the server all releases (for clairification, when i say “release” i mean a record or records that were released by a label as one unit) exist and once one user enters in a release, it is available to all users.
The client-side will be designed to take information from the central server, and display the users own releases which they have picked. I plan to release the cleant-side in a couple versions: the main version will be a php script people can install on their server to display, and I also plan to design plug-ins for popular Weblogging and CMS systems.
Now, the tricky part of the process is getting the information from the server-side application to the client-side. I thought about using RSS feeds to get this done, but that’s a huge load on the server, so I’ve decided to try something a bit different. My idea is to have users log in to the server and they can request an XML formatted list of all their releases. They’ll be able to copy and paste this list (or upload a XML formatted file) to their cliean-side application, and it will parse the list and add any new releases to their database and it can be displayed.
So basically this system does two things: it keeps a record of what releases a user has on the server side, out of all releases available, and the user and display their releases to everyone else via the client-side applications.
Now this is just a rough idea, and any suggestions are welcome. Please a comment or contact me
Obviously, I’m going to design the server-side first.. but the most complicated part will be getting the databases designed right the first time.. I want to build this so that if the project does get big, I don’t have the headache of having to revamp the databases at a later date.
2 Comments
Good idea, Dan. And yes, you’re right.. leaving input up to the user could spell disaster. Using HTTP POST might be a better option than having the user copy and paste XML.
Well, I think RSS is a bit of a stretch, and this isn’t what it was designed for anyway, but you could do binary XML (or regular XML) with no trouble. Pull the data out of the database and format it into an XML file then send that to the client. This is actually trivial to do, and is a very inconsequential load on the server in comparison with some stupid shit people do from time to time.
The best way to do it is to implement a SOAP interface using e.g. the NuSOAP PHP package (which I can install if necessary). That way, the application (or anyone’s application) can essentially do remote ‘functions’ and get data back from the server that way - a much better way of doing things like that, but only really more useful when you’re going to be having multiple programs doing things and you want to be able to publish a standard API.
Transacting with the server in XML, however, is certainly a workable idea, and is probably, at this point, the best way to implement the client/server interface and still have a web-capable interface as well. Making the user do anything manually is a recipe for disaster in terms of usability and market penetration.