Author
|
Topic: New version dead in the water? (Read 6807 times)
|
lisaviolet
emAlbum Pro
Full Member
Posts: 54
|
 |
New version dead in the water?
« on: November 09, 2007, 09:05:36 PM »
|
Reply with quote
|
If so, please let us know. I'm looking to upgrade and because I've got so many images, it's going to take a while and the sooner I know, the sooner I can get started.
Thanks.
|
|
|
|
Eric
Administrator
Posts: 2761
  
|
|
Re:New version dead in the water?
« Reply #1 on: November 10, 2007, 09:49:38 AM »
|
Reply with quote
|
Hello,
Sorry I haven't posted anything regarding v2 for a while. Unfortunately, the reason is because I haven't been working on it.
I still haven't decided the direction to go with emAlbum. I'm looking to switch over to using an existing framework, but there is a limited selection in Perl. Which also makes me wonder about switching to PHP.
I will be releasing something new for emAlbum...I just don't know what or when at the moment.
Sorry...
Thanks,
Eric
|
|
|
|
|
|
shushl
emAlbum Pro
Newbie
Posts: 21
|
|
Re:New version dead in the water?
« Reply #3 on: November 07, 2008, 09:50:41 AM »
|
Reply with quote
|
Any news on the new version or this project is dead forever?
thanks
|
|
|
|
Eric
Administrator
Posts: 2761
|
|
Re:New version dead in the water?
« Reply #4 on: November 08, 2008, 07:13:17 PM »
|
Reply with quote
|
I'm not ready to throw in the towel, but as of right now, I seriously lack the time necessary to continue a re-write.
As mentioned in other threads, I have considered switching to PHP (on and off), and am still undecided. I know that the code is in serious need of updates.
I've also considered turning emAlbum into an open source project to try and get input from more people - but again - am undecided.
With all of that said, emAlbum still continues to be one of the top galleries available and I appreciate all of the support and interest I've received.
Thanks,
Eric
|
|
|
|
StormB
emAlbum Pro
Newbie
Posts: 9
|
|
Re:New version dead in the water?
« Reply #5 on: March 16, 2009, 07:53:46 AM »
|
Reply with quote
|
Quite frankly, if I want a php based album then I look to Coppermine, 4Images or G2, all of which have a large development base, a large body of plug-in developers, a mass of features, have been around long enough to be stable (theoretically) and which are free.
Why reinvent the wheel and knock yourself out in the process?
When I want a gallery that doesn't need user-upload, groups, permissions, visitor comments, and the swiss army knife of optional extras, I don't want php and mySQL. I want something which simply displays images quickly and neatly without a lot of server overhead, without relying on the database being in a good mood, without the potential for security loopholes and which works.
For that I keep coming back to emAlbum.
I've tried most of the other non-php galleries including ImageFolio (both the free and commercial versions). emAlbum is better and I don't mind paying $25 to use it. So why isn't it more popular? Unfortunately the fault is not in this script, it's in the web community's belief that everything should run on LAMP or, heaven forbid, it's illegitimate offspring Ajax...
Anyway, if this post has any point except to rant, it's that you have a product here which fills a niche in web site development so, to me, it makes more sense to exploit that niche more effectively by marketing the qualities of perl over php for certain tasks, rather than becoming a small fish in a very large and already over-populated pond.
|
|
|
|
Eric
Administrator
Posts: 2761
|
|
Re:New version dead in the water?
« Reply #6 on: April 07, 2009, 04:05:21 PM »
|
Reply with quote
|
StormB - thanks for your input.
Unfortunately, I haven't used Perl for anything of significance in over 6 years. My focus has been on Java, PHP, JavaScript and C#. So, in order for me to actively maintain something, I want it to be in a language that I am proficient in. Out of the languages I have used, I think PHP is the most accessible to the broadest range of people.
I don't believe in reinventing the wheel...just making it better. emAlbum is proof of that. I am confident that whatever I release will be unique enough to stand on its own, regardless of the language or "competition". It may sound crazy, but I don't spend much, if any, time evaluating what other gallery scripts have or are doing. I created emAlbum based on my preferences and then incorporated features requested by users.
I would love to model the next version of emAlbum after something like Flickr. The biggest feature I want in emAlbum is the ability to highly customize the interface. Many of the gallery scripts you mentioned all look alike...just with different colors 
I think it would be great to still have at least 2 different version of emAlbum. One that is single user based without users, comments, etc. and another that is more community based with social features. Either way, I would like to have both versions be database driven as it would greatly reduce the amount of coding involved.
As you can tell, it has never been about anything other than the satisfaction of providing something useful - that has been used by thousands of people. If I were in it just to make money, I surely would have charged much more than $25
I think that if I would have kept up on releasing new features an updates, emAlbum will be much more widely used - but you are correct, PHP based galleries certainly have a bigger draw.
Again, I appreciate your input and usage of emAlbum. I'd love to hear any additional thoughts you have, including to my response.
-Eric
|
|
|
|
jurgennijhuis
emAlbum Pro
Newbie
Posts: 8
|
|
Re:New version dead in the water?
« Reply #7 on: April 09, 2009, 04:43:33 PM »
|
Reply with quote
|
For client of mine I spent the whole day looking for a gallery script (all kinds, that run on Linux) that has the option of showing all or certain category links on each page. NONE of them does that. They all use bread crumbs and/or dropdown menus for navigation. My client wants all category links of a certain level to be allways visible on each page. Some scripts come close by showing a tree menu to all categories, but that's an all or nothing approach.
Most gallery scripts look so much alike, it's frightening. All modern scripts can do the same, and do it good. But none of them is flexible enough to be used within an existing site, by offering a simple way for designers (non-programmers) to let teh gallery function and look like they want. Plogger may be the best option for that I guess, so I think I'll use that. But it should be much more flexible.
So if you're looking for a interesting 'hook' for a new version, I'd suggest to go for flexible 'pseudo' programming options. And yes, PHP would be the best choice, becasue it's the most used language, and you could (should) use include functions for the script to use within other sites and cms'es
|
|
|
|
StormB
emAlbum Pro
Newbie
Posts: 9
|
|
Re:New version dead in the water?
« Reply #8 on: April 11, 2009, 02:18:11 PM »
|
Reply with quote
|
Hi Eric
I'm happy to provide what input I can though I'd have to say my own specific needs probably don't mirror those of most users so I'm not sure how useful they would be. I also tend to be very opinionated as you may have noticed
Anyway, yes customization is good providing it is easily accessible. That is where most galleries fall down because it can't be easy to create a way to significantly customize more than the basic paint job without expecting the user to be at least proficient in CSS. For more significant changes, people tend to use Smarty but as an end user I have never found that to be either friendly or easily accessible without spending a lot of time on becoming proficient. And of course, some galleries require you to use their templating system and either know PHP or rely on someone else to have already created something you can use. So to my mind, the easiest thing to work with is to have the gallery topped and tailed with HTML header and footer, then provide an easy way to change the basic gallery paint job and style from a predetermined list. That might make it easier to design versions that embed within a CMS too, but I'm just guessing on that because I'm not a programmer.
I'd tend to agree that a gallery basic with most of the extended features available as optional plugins gives the flexibility people expect without needing them to hack the script. On that basis perhaps it only needs a single version with the social features available as an optional extra?
Looking at it from a personal perspective, what would make me consider changing from the mix I currently use? -
- Security and stability - probably not before any new php script had been released for at least a year because php is the most prevalent source of server hacks when it allows any sort of user input. Having had to remove several scripts that allowed the installation of zombies and having had my own server taken over and used as a spam server due to a loophole in a php CMS that had been around for several years I'm very paranoid about that aspect.
- Ease of use so I can get it integrated into various sites, of course. See above.
- Updating - PHP scripts always seem to need regular update versions. The worst for this was 4images which went through a phase of updating for security holes every few weeks and which could only be updated by overwriting the existing script, thus also overwriting any mods. So being able to update a gallery that uses an isolated core script and doesn't wipe out any customized aspects is a big plus.
- Stability and speed - for me the biggest bottleneck is calls to the database. As I mentioned before, mySQL may be good but it can only take so much overhead and the more features you add to a gallery, the more tables and the more calls it makes. I had to spend weeks removing a lot of dynamic content from my own php gallery installs because they brought the server to its knees at peak times, with page loads taking minutes rather than seconds. Naturally this won't affect much anyone who runs a single gallery so it may not be relevant to anyone but me, though when you add in a php CMS, message board, etc etc, it all puts pressure on the database.
- Social functions - I think they are expected in any serious modern gallery system
- Easily configurable and granular permissions setting via usergroups
- Interim sizing of images - having a default mid image size that displays when a thumb is clicked and which can be set to fit the average browser window, with an extra click-through to the full sized image. Sounds obvious but not all galleries do this and it can be very frustrating for surfers.
- Stuff like mime types, automatically generated emails, server resizing of images, custom thumbs upload, you would know far more about than me and they're pretty standard.
- Upload options - G2 has a very nice java upload feature which is great for gallery users but G2 doesn't have direct FTP upload. 4images has FTP upload but the front-end option is clumsy for more than a couple of images at a time. I'd prefer to see three options - single image upload from within the gallery, multi-image upload from within the gallery which doesn't require browsing and naming for each individual image (drag and drop onto an interface preferred and the uploader processes those images one at a time so it doesn't fall foul of the usual 8Mb php upload limit), and behind the scenes upload via FTP with the gallery capable of reading the new images and adding them to the database once the upload is finished.
- Using something like ImageMagic to create thumbs and mid-sized images seems common but having the ability to also upload these via FTP can cut a lot off server overheads for big quantities of new images.
Those things are all existing to various degrees in different galleries but I don't think any one gallery covers all the bases. Life is a series of compromises and so are php scripts, in my experience
However, there is one thing that none of the galleries do and which may, in any event be impossible. It may also be something that no one but myself would find important enough to justify its existence, though if I found a solid script that had it as an option I would certainly pay $500 for it. Maybe more.
My personal dream is to find a gallery which has a single install of the system files but which allows albums to be created in individual sub-directories which can each be password protected using htaccess/htpasswd. The gallery main script would carry all the operations and only need a single place for any updates and customizations, the sub-directories would carry individual album trees with minor local customization such as album titles and perhaps color scheme.
So you'd be looking at installing and maintaining the gallery in one place only. But each album could access the working parts of that script to display images within a self-contained directory. That would allow customer access to a single album and its sub-albums based upon sale of a password that worked only within the specific directory for which it was issued, while minimising the work of maintaining and configuring the actual gallery system itself.
Well, I can dream but then, as I said, I am perhaps in a fairly unique position since I run some 200 individual mini-galleries within a single domain, all of which currently require a complete gallery installation to make them work and all of which have to be installed, configured and updated individually. (I know G2 has a multisite option btw, and I had hoped that would be the answer but adding a new album location still requires a full installation script to be run and any changes to that gallery core still require an update script to be run on every satellite installation. Also once you upgrade the core script, the satellite installs won't run until they have had their own update script run too. Probably G2 is complicated because the satellites can be installed on multiple domains, I think. Having it limited to within a single domain should make it simpler (another guess).
Database would benefit too because at present each install requires a full set of tables (probably adding up to 12,000 tables spread across a number of databases within mySQL I estimate). Wheras with a single gallery install all the image data would be in a single set of tables and served based upon their location code.
Actually, thinking about it, I'm sure I would pay $1000 for a script that achieved what I wanted, if I had the money available, simply based on the time and hassle saving.
Anyway, that's my thoughts so far, or more likely, that's a wish list of bits from various existing scripts I'd like to see in one place, along with a pie in the sky 'wouldn't it be wonderful' flight of fancy 
Hope it helps and while I don't have time to volunteer for beta testing or anything remotely useful, I'm never short of opinions should they be needed.
|
|
|
|
|
|
|
Logged