Web interface/client?

[mastermind]

Greetings.

I've searched through the forum, and I see that a web interface for Griffith has been planned for the future. I've had an interest in such a feature for a long time.

What's the status? Is this a work in progress, only a planned feature for the future (i.e. planned, but work not started yet), or has the idea been abandoned?

I'm a web developer, and if there is anything I can do to help give life to a web client for Griffith, I'd be happy to help.

[mike]

Help is always welcome.
There is a prototyp available which isn't complete at all.
The last version which I got can be downloaded from here:
http://mitglied.lycos.de/codestuff

There are two threads in the forum about such a web interface.
English thread about an online version of griffith:
http://forum.griffith.cc/index.php/topic,282.0.html
German thread about an online version of griffith:
http://forum.griffith.cc/index.php/topic,202.0.html

I don't know if a developer is working at a web interface at the moment.
You can start a new project if you have enough time and experience.
I would be happy. And a big number of users too.

Regards,
Michael

[mastermind]

I'm thinking that if we're to create a web interface for Griffith in the first place, it should be possible to add movies there too.

My immediate thoughts on what challenges we would probably encounter:
 * Authentication. We should add a user authentication mechanism, probably by adding a user table to the database. This MUST NOT interfere with the operation of the current Griffith application and should only be considered plain additions - no modification of existing db objects
 * Storing images in the database would be a great advantage, I think. However, as long as the original python application requires posters to be stored as files, this would break a full compatibility between Griffith and the web UI
 * Fetching from IMDB, Amazon and others. How simple will it be to port the fetch mechanisms to the web UI?

[mike]

You are right with the challenges. But I think at the first steps there should be a limited number of features.
Most projects fail because of too much goals for the first milestone.

In my experience it is most important that the end users are stand in the middle of the development of an application.
That means the first features should reflect the needs of the most users. As I can remember of other threads
in the forum it is most important that the user can query the database with a big number of search criteria.
The second most requested feature are reporting features like generating pdf documents.

Some other requests are the following (apply to griffith and a web client):
* easy selecting of different databases
* one database for griffith application and the web client
* of course, a better solution for the poster storage which can be easily shared between different computers
* an installation procedure which is as easy as possible

Of course if the first milestone is reached there would also be request to add features for modifying and adding database
entries. The authentication would be a feature request too. But I think that should be realized with the second or third milestone.

The fetch mechanism can be easily ported to a web interface if it is written new from scratch. But that means that the
maintenance effort is doubled. A better solution would be the integration of the original python plugins. That should be
possible as long as the plugins didn't interact with the user. But it breaks the request for an easy installation procedure.
The most web servers didn't support python without an extension.

[mastermind]

Don't get me wrong. Although I admit that it didn't show well in my previous post, I'm a "make it simple" kind of guy. And the phenomenon you're referring to - projects being abandoned because of too high initial ambition levels - is not at all unfamiliar. Planning is however important, and if you take the "cautious" approach too far, you'll be thinking ahead in as small steps as you're walking. Point is; it's important to take small steps at a time, but always think and plan way ahead. That way you can avoid hitting the wall, forcing you to rewrite large portions of the code.

I don't think we have any disagreements here. I understand your point with the maintenance burden of having separate codebases for the fetch mechanisms. I also share your view of how the users should be the driving force when deciding which direction to take in development.

The question is now, what is the best way to proceed?

I know that the admins have been enthusiastic about the idea of a web interface in the past. I can however not see that the svn/cvs repository for griffith is available to the public (maybe I've missed something?), and e.g. working on a separate trunk for the web UI in the official griffith repository doesn't seem to be a possibility (maybe I'm wrong?).

It would be pointless if each of us try to "re-invent the wheel". I'm sure there exists several small "prototypes" of a griffith web UI. We would be able to accomplish so much more if we join forces. We should preferably (IMO) not be more than a few people to begin with, though, until a code structure has been established and the first milestone reached.

We could co-ordinate our efforts and have technical discussions in the open, f.ex. on IRC

[mike]

Sorry for my late response. I was a little bit busy last months.
I hope you still want to write a web UI.

The griffith repository isn't available to the public for write access. But if you have a BerliOS account you can be added to the griffith development group and get write access. But we could start a new open source project too. That would be a much better and clearer way to development the web ui separated from the griffith application. Sure, with that scenario it is a little bit complicated to share sources.

Michael

[parti02]

Hi all,
i start to write a web client, 1st. idee was only for myself, but perhaps it is possible to make it public. Some things are a bit more difficult when i or we try to make a public version.

What works:
I have a design based on a template from coppermine gallery, a main header which sort the database entries on "newest","0-9","A","B"etc,"Top Rated" and a search funktion which can search nearly by all film properties.
A admin site which managed a user (admin) and the database-connection with error-handling, some settings like language, theme, and movie-database can set on the admin page, too. All settings saved in textfiles. Language, theme and movie-database are without funktions, yet. With the user handling on textfiles, it is easy possible to handle more user, so you can configure, if not registerd users can see anything on your site or not.
So, i implement a automatic cover download from ofdb.

Now my problems with the public version.
It is easier and realy more faster, when all informations about the movies are in the table "movies". Why griffith use so much different tables? Now, the informations in the table "movies" only are not enough. One simple and easy solution to get first aplha webclient, could be to add a few more "notes" fields inside "movies", so you can configure the notes fields are shown and how they called on the admin page.

Why griffith don't use the original filename from the movie database for the poster inside the mysql database?
I think, when there is a database entry for the site where the movie informations get, we need a second entry with the url for the pic.
So it is not a good idea to write a php wrapper based on the site url to get the poster, for every movie database.

How get the movie informations download to work? One way is to write it in php for every movie database, but then you invent the wheel a 2nd time, and you have to support two download wrappers, webclient and griffith, if something change on one movie database.
Use the py files from griffith is a very easy solutions, but then the software runs only on root server, where you can change the php settings and install software, very bad idea i think.
Any solutions? One way, but it is hard work, is to write the py files in something that can read from python and php, perhaps xml files which contains only informations how to handle the questions on site xy..

I think a griffith online make only sense with 100% compatibly to the original.
What are you thinking?

sry for this very bad english, i hope you can understand it although.
Gruß
Parti

[nahkanunna]

Why griffith use so much different tables?

That is called database normalization. To get all information you have to use joins. Unfortunately I haven't looked at the table structure so I can't comment how well defined it is but I'm sure there's valid reasons in using multiple tables.

Does anyone know where the schema is btw? Because I was planning a small web catalog that would pull stuff from Griffith DB myself. It would use mysql, PHP, smarty, with fully localizeable strings and layout.

[mike]

There are no official database schema.
I tried to produce a model with MySQL Workbench. It is available here: http://mitglied.lycos.de/codestuff

[parti02]

Yes thx, i already found something about normalization in selfhtml, and my database requests with joins are working. I am working on simple user managment, yet.

[parti02]

We should preferably (IMO) not be more than a few people to begin with, though, until a code structure has been established and the first milestone reached.

We could co-ordinate our efforts and have technical discussions in the open, f.ex. on IRC

Yes, you are right.
Is there any existing code for a webgui, yet?
I startet to write a webgui, it is very far from finish, but some things are running.
Perhaps someone want to have a look on the code, yet, so we can decide if it is a possible base for a griffith online version and the code is going into the right way.

What works
Configure Admin user and Database with error handling.
Elementary user manager (site can work in public and private mode)
support most database entries (read only)
The style is based on a coppermine theme (only small changes), so we have a few different styles.
Automatic poster download from ofdb. (i think it is easy to support posterdownload from all moviedatabases, when griffith 0.10 is released).
Search.

The code was developed on an database with ofdb entries only, perhaps some things don't look perfect, with other entries, because it is not testet. This version don't write to the database, so you can have a look on it without any danger for your database.

Note: It was started only to view my own movies and to learn php, don't be so hard to my code. The idea to make a griffith online comes later...

I am interest to hear from other developer.

Regards
Dirk

[POX]

FYI: I plan to make a Pylons based online version of Griffith (well, probably read-only, i.e. adding new movies will be possible only via Griffith). That's why I moved ORM stuff from sql.py to db.py and why I want to rewrite export plugin system (using mako)

[parti02]

but python is a requirement on every running system?
PHP, Apache and Mysql, too?

Gruß
Dirk

[POX]

WebGriffith 0.1~dev (still long way to 0.1 final) is in our repo. I'll explain how to start it later (once 0.1 will be ready).

[siafulinux]

Hi Guys

I had come across Griffith the other day and almost immediately wanted a web interface. So I started working on one and later found this forum post. Thought I'd share what I've done so far and see what kind of feedback I get. At this point in time it's nothing spectacular and I've just begun, but let me know what you think and any ideas you may want to share.

Keep in mind this was just a simple project for myself and I wasn't aiming for anyone else at the time, but I now realize others may be looking for something similar.

http://www.siafunow.net/movies

Thanks
siafulinux