Random Image
Gallery 3 Begins
Submitted by ckdake on Mon, 2008-12-01 18:17
Those of you that have been paying attention know that something is going on! At the Gallery Sprint a few weeks ago, we made a lot of decisions and got the ball rolling on a complete rewrite which we've decided to call Gallery 3. Development of new features on Gallery 2 has been frozen, Gallery 1 is now a completely separate project "Jallery", and the Gallery team is now busy at work on Gallery 3. It's definitely not ready to run on your website yet but we've set the ambitious goal of having a 3.0 release by February 1, 2009 and are on track to meet that goal. Read on for details of why we're doing this and what you can expect.
Gallery 2 today
As lots of you know, Gallery 2 does a pretty good job. It's a secure way to put your photos on your website, and if you want a feature, chances are pretty good that it is hiding in there somewhere. Over 3 million of you have downloaded Gallery 2 (compared to 2 million+ that downloaded Gallery 1) so we are obviously on to something, and we have received hundreds of positive testimonials about how Gallery 2 has made people's lives easier. It's been a huge effort and we've been happy with its success.
So what's wrong with Gallery 2?
Gallery 2 does many things for many people and this diversity has made it unhealthy. The code base is too complex and over-engineered because it was designed to fix every single thing that was wrong with Gallery 1 (Second System Effect) leaving its scope hazy and broad. And while the Gallery 2 code supports DB2, MSSQL, and Oracle we don't actually have anyone on the team that knows much about them, so there is nobody to fix bugs or add features in these areas. Gallery 2 was designed from the bottom up with architecture and design patterns first, so the User Interface and User Experience need a ton of work! This is shown by the huge number of strings and documentation that need to be provided in the product for people to understand it, and multiple attempts for tech writers to document Gallery 2 have all failed. Lastly, the product is immensely complex which forces developers to take months or years to get up to speed. This makes it very hard to attract new developers, and that makes us sad.
Hopefully by now you don't need any more convincing that it's time for Gallery 3! We've started from the top down with User Experience as the highest priority, only writing code for things that make sense for our users. Simplicity is also a high priority: both for users (the UI) and developers (the code). We learned our lessons from Gallery 1 and Gallery 2, and are hoping to finally get this right. You probably have some questions in your head and we'll do our best to answer some of them below:
Is there still room for Gallery 3 when there are sites like Flickr, Smugmug, and Picasa?
Since the beginning, Gallery has been "Your Photos on Your Website." None of these services really let you do that, and your data is with someone else. While these services meet the needs of plenty of people, there will always be people that want to have complete control over their website and the way it looks. Some people will want to customize their themes in a way not possible with hosted services, and others want their images on hardware that they own.
Since Gallery 3 won't do all that Gallery 2 tried, what is its scope?
We've made a list of features that we think are important to have. That page includes a list of features that we will implement, as well as a list of features that we'd like someone to be able to implement but that won't necessarily be part of the core product.
You mention decreasing platform complexity, so what platforms are going to be supported?
We aim to create an amazing product that at least 80% of you can use. We've decided that the most common platform, available to all (even if it's not what you're using now, it's something that you could be using easily) is Apache 2, PHP 5, and MySQL 5. This doesn't mean that Gallery 3 won't ever work on alternative platforms, but it does mean that the existing developers aren't going to go out of our way to make it work there, at least not for the first release. If Gallery 3 works on Windows + IIS + PHP perfectly without us trying, that's great, but this policy lets us take advantage of unique features of Apache and MySQL that are not available on other platforms. If you'd really like to see Gallery 3 work on some other platform we invite you to come talk to us. Seriously! Corporate support is welcome as well: for example, if Microsoft would like to own our Windows Server support and is willing to do most of the work and QA on that part, we're definitely willing to cooperate on that.
Where can I find out more?
We don't have a great starting place yet, but the best place to start is the Gallery 3 Category on our documentation site. Everything that gets documented should be in there. There is also the Gallery 3 code in subversion and our shared task list in Chandler. If you want to find out more or pitch in, we have a few paragraphs on that as well.
Great, this reflects many of my thoughts about gallery 2
Sounds nice. I hope one of the top priorities is efficiency.
Right now Gallery2 is not usable on a high-traffic domain in a shared hosting environment. Per a forum thread I started a couple years ago, each image clicked requires 25-30 database queries? Yeesh.
I realize Gallery is freeware and all, but right now it just doesn't scale under load.
Great, So now you have moved on from Second-system effect and feeling Third-system effect.
I agree Gallery2 has become bloated and over complicated even for the simplest of things, but I hope reinventing Gallery and creating Gallery3 will be well worth it to the Gallery project as well as the community surrounding Gallery. Also I disagree with the list of features and think that the cart should be considered for integration into Gallery3 if not in the first release then in future releases.
Sounds great but I would be very careful with cutting some platform support.
Your prime focus on Apache 2 + PHP 5 + MySQL 5 is too narrow-minded. I know a lot of friends (not including myself. I am Linux,A2,PHP5,MYSQL5) running Gallery 2 on Windows 2003/8+ IIS 6/7 + MS SQL 2005/8 + PHP 5.
Yes, there are a lot of non-Apache & non-MySQL Galleries out there.
Focusing on MySQL 5 and using specific features of it will definitely be a dead end street and you may loose lots of satisifed "customers" which at the end may degrade Gallery's reputation.
So please, act wisely with such decisions.
Regarding the database support, maybe a database abstraction layer (class) would be a better solution to shield Gallery from the underlying database infrastructure. It could be easily adapted to new DB-engines and people with specific knowhow could focus only on that part of Gallery without having to know all the code of Gallery.
Regards
Oliver
I agree with Fotographer's comment: Gallery3 without a cart/payment/download function won't be any use to a lot of us, myself included. One only needs to have a look at the top feature requests for G2: The PayPal addon is fourth on the list (this need has been filled for G2 by alecmyers' outstanding effort with checkout http://codex.gallery2.org/Gallery2:Modules:checkout).
I think this is a good move. I've been "stuck" with G1 all along since G2 didn't turn out to be interesting. Focusing on a few feature and make them work really well is a good thing.
It's funny that the Gallery team talk about how G2 "does many things for many people" and how they're narrowing their focus and then the some of the comments are all about adding more features and supporting more plattforms :D
AdrianB -- exactly! The way to create a high quality product is to choose your scope carefully. So for this first revision, we're going to create a really good product for viewing your photos on your website.
We will design the product such that it is easy to add new features like cart, payment, etc as 3rd party modules. Those that are highly motivated to have this feature can help us to implement and maintain it, just like we did in Gallery 2.
As for platforms, yes there are probably a lot of people who are running on other platforms. But they *could* be using Linux/Apache/PHP if they wanted to, so they'll have to make a choice.
Which would you rather have: a good product with limited scope available on February 1st and released regularly after that, or a mediocre product with a huge scope released at some time in the distant future and released irregularly? Enlarging our scope turns the former into the latter. And there's nothing to stop you from continuing to use Gallery 2 if there's a feature that you *really* need that Gallery 3 doesn't provide right away.
Sounds interesting. I can't get the trunk to checkout via svn though. I feel like I'm missing something. =(
It really is an ambitious goal to release Gallery in Feb 2009, which is only 2 months out and with the holiday season arriving soon.
Feature wise, can we have background music which is now a missing component.
Woohoo! I've always loved the functionaliity of Gallery2 but thought it was missing a little polish, can't wait to try out Gallery3
I'd also like to put in my vote for the shopping cart and I think background music is a great idea too.
Background music will not be part of G3. It will be up to the community to offer a module or a theme to provide that functionality.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Background music is in the same category as the shopping cart and similar ecommerce features: we won't write those as part of the Gallery 3 core but we will make it easy for the community to make their own plugins to add these and many other features. Right now it is very easy to add powerful new modules to Gallery3.
Cheers! I totally agree with the idea that the new concept for Gallery3 is simplicity, in part of the complexity of the pervious version that drives me crazy and in part of the Web2.0 trends of the ability to keep it simple and fresh!
looking forward to testing Gallery 3! Will the "Maintenance Tasks" feature in G2.3 be a separate module in G3?
Without the background music would not be a big disappointment for myself.
Currently only activating a few modules which are really necessary. A simple one with better speed is equally good.
I'm sad to see you saying things like full rewrite already. I understand the reasoning, but I hope this will be the last for a long while - I've built much on gallery, but I can't bring myself to spend more time on it because, like many OS projects I've worked with, it seems my time will be wasted in another vast rewrite.
I'll cast my vote, as if I had one, for performance and scalability coming first and all else second. This may be hard to believe, but I have massive gallery2 gallery's of high megapixel images on Win2k8/IIS7 that run very fast.
IIS support is mandatory for me, I've built a dozen gallery sites over the years, and only one is on apache2 - gallery2 runs painfully slow and management is archaic to me. But then, as usual, I suppose IIS users will have to fend for themselves in the open source world.
@glennpratt: After spending the last 8 years participating in two complete implementations, I too am hoping that this will be the last rewrite. We've learned a lot in the past that gives us some confidence that we'll get it right this time. But as you're experiencing, part of getting it right is limiting the scope of the product. You can't build a product that is all things to all people, while still small and fast. We'll build something that's small and fast and is most things to most people. Those outside the mainstream will have some tough choices to make, but this is all we can reasonably offer, at least for the first release.
My vote is for the shopping cart & paypal / google integration. I rely heavily on the module.
Thank you for a great G2!
I am hoping to see a much better search function. Boolean or a smarter search is still my biggest request. Stability and speed have been fine for our Apache-based 20K image gallery, but I know others have much larger sets to worry with and may not have had the same speedy results. The only other request I could think of would be to make it easier to theme/customize.
Thanks for all the hard work on making this available to us.
As it stands right now, I can't even use Gallery 2.3 in a totally clean installation. It simply locks up when trying to login as the admin user.. even with the installation going without a hitch. I am currently looking at other gallery scripts that I can at least log into and do work, but they have their issues as well. I think the Gallery 2 code got to be a bit too complex.
I might try again with the barest minimum installation with no extra modules installed and see what happens, add one at a time if it works and see which one causes it to bomb. In any event looking forward to the new release.
Mark H.
I'm very satisfied with the Gallery2.
From my point of view this features are most necessary in Gallery3:
- user size limit
- user album (automatic creation of user album when user is created)
- hook of the latest (random) picture from the site outside of the Gallery (<?php @readfile('http://foto.oratorij.net/main.php?g2_view=imageblock.External&g2_blocks=randomImage&g2_show=title'); ?>)
- multiple installation
- gallery remote
- resizing of images on local computer, as my conection to the G2 is quite slow
- easy theming
- easy upgrading from G2
- if possible, same ID numbers of elements (I have a huge linking sistem to albums and photos from outside of the gallery) – even if the url address in formed in a different way than now
- importing of the current translation strings (I’ve spent quite a long time on whole translation to my language).
Thanks.
I was curious as to why you chose the Kohana framework versus CodeIgniter, cakePHP, or Zend?
Gallery3 - "Third time's the charm".
Hi,
I did not find anything about mebedding G3??? This would be sad, if there is no embedding possible any more.
BR Markus
@jureb: thanks for the prioritized feature list! I'm happy to say that almost all of those features are on our list (although we may not have them ready for Gallery 3.0).
@Fotographer: We spent several weeks evaluating different frameworks. I've added a FAQ showing our thought process here: http://codex.gallery2.org/Gallery3:FAQ#Why_did_you_choose_Kohana.3F
@markusw: Embedding is definitely on the list, don't worry!
I didn't notice anything in the Admin features for version 3 that would allow me to moderate the images that are uploaded - I would like to be able to approve or not approve images that members upload. Will this be available in Version 3?? I have the Moderate module installed with Version 2, but it's not working - people are uploading images without my approval being made before they are shown.
I like where this is going! I was thrilled to see that the newest 2.x branch was available as a download with only english language included, since ftp'ing .po files for all those languages you will never use was such a hassle. I have also gone from G2 full to standard and then to G2 minimized version. Even that minimal one is still feature rich and easily extendable.
G2 has worked very well for me for some time now, but I agree that even the minimal version could seem a bit bloated to someone without high demands for functions. Of course the point about it being too hard for developers to learn is at least as important, so I'm glad you reached a rewrite-decision.
For the ecommerce guys (read: those who use this free software to make money): Can't you just [join forces and] fund 3rd party developers to create your needed commerce extensions? Remember this is free software, don't let the moneymaking features halt the fine-tuning and further development of the core, which we ALL benefit from.
To the Gallery devteam: Keep up the excellent work! Sticking with an o/s, free project like this for 8 years is damn impressive, Bharat - props, and thanks a lot for the continued effort! Very much appreciated.
This looks exciting! Gallery 2 is/was great, but it's so complex that it's impossible to develop for unless you invest several months of time (and even then very difficult). I've tried modifying it and writing gallery plugins, but was always frustrated by the process and more often than not, gave up. I'm very happy to see that the core team recognizes that this is an important issue, and are working to fix it. As someone who has also worked a lot with WordPress (hacking and writing plugins, nothing formal), I've found it to be a very powerful but developer friendly application that's easy to learn and work with - hopefully Gallery can reach the same (or higher) level of power/ease of development. Can't wait to see how this turns out!
Also I'd like to chime in (yet again) and say that perhaps permalinks or url rewrite should be included in G3 because the g2_ links (ex. www.yoursite.com/Gallery2/main.php?g2_view=search.SearchScan) in G2 are a dead giveaway if you want to hide the fact it's Gallery (nothing to be ashamed of) or if you want to make Gallery more SEO friendly and the permalinks module for G2 didn't always work for all instances, and I think it would be a great addition if not in the first release then perhaps a future release.
Gallery3 - "Third time's the charm".
I like that you have chosen Kohana and use components of Zend Framework.
Was the background music request a joke? This can be added as a module later.
I agree with the small scope
- Database abstraction would be a great start (MySQL, PGSQL, MSSQL)
I agree on concentrating on getting it to work on one web server first (Apache2) to meet the February release.
I don't know about what additional changes have to be made to function on IIS. The PHP projects I have done usually just require path modifications.
---
It is a damn poor day when you don't learn something
Sounds great, keep up the good work!
Actually, in the same category as my last reply Gallery3 is being built upon Kohana which uses the MVC pattern so I guess nevermind about my last reply because the MVC pattern is very good (in my opinion) for SEO as well as a good architecture all around.
Gallery3 - "Third time's the charm".
an Amazon s3 integration would be really useful I think.
Generally I think this re-write for architectural simplicity is great news
But as several people have already commented, I too have developed a number of custom code modules and themes templates for my site and I really don't have the time to re-write them from scratch... I suspect the same is true for the authors of the large number of publicly available 3rd party modules & templates. So for G3 to build on the success of G2, it will either need a G2 compatibility mode, or only require fairly trivial changes to existing code (as has occasionally been the case with changes to the G2 API).
Failure to provide this is likely to cause many G2 users to re-evaluate their loyalties - if one has to re-write custom code from scratch in a totally new environment then there is no particular reason to continue using Gallery - there are many other products out there, and things like the Flikr API allow one to create the user-experience of a fully customised website with a great deal less work.
Other than that, I echo Nosaj's request for a proper search engine that can see XMP/IPTC/EXIF data as well as caption and title, etc fields. Searching on G2 is embarrassingly simplistic by modern standards... having read through a number of threads on the subject I understand that one of the reasons it's never been properly tackled is the sheer complexity of creating the SQL queries that work across all supported RDBMS platforms. I hope that G3's focus on mySQL as the primary platform will make this task a great deal easier... so please make it part of the core code (even if it's not available on 1st release).
I'd also suggest having a good look at the products used by professional image libraries for some feature / usability ideas. In particular a user lightbox would be very useful (although probably best left as an optional module).
Anyway, all the best for a winter of hard coding ;-)
Dominic
http://photographicon.com/
- I think it's pretty much a dead cert that all user-contributed modules will need a total rewrite from the ground up - BUT, the particular reason to switch to G3 (note: not to "continue using Gallery" but "switch to G3") will be that G3 will offer the best performance and up-to-date features going into the future. Remember that G3 is being written by the same team that wrote G2, and they're not relying on brand loyalty to make G3 attractive, they're aiming to use their skills - already demonstrated on G2 - to make G3 best-of-breed in its own right. Also G2 will still be available, for those for whom it remains suitable and/or who don't have the time to rewrite their must-have modules.
Remember that the Gallery concept is "your pictures on *your* website" - Gallery (not even G3) is aiming to compete with 3rd-party hosted solutions that allow partial access to various APIs - that's a different solution space for a different class of problem. Gallery is aiming (always has, and will continue to be, we hope) the best available solution where you maintain control of 100% of the code, and can modify any and all of it for your own purposes.
That remains to be seen... if G3 really is a total rewrite of all code, then it'll be at least a year before it's stable and bedded in enough to actually evaluate whether it has "best performance and up-to-date features".
I suspect that as time goes on and 3rd-party hosted solutions develop, then the need for so many people to have their own picture on their own website will start to diminish. The point I was making is that you can only walk people up the total re-write hill so many times before they get tired and start looking at other solutions more favourably.
Dominic
http://photographicon.com/
Possibly - that's down to the Gallery team, though. I'm not brave enough to make predictions of that sort.
It's explicit in the aims of G3 that a sizeable proportion of current G2 users are *not* going to find G3 suitable - certainly not to start with. A deliberate decision was taken to include the features that (at a guess) are needed by 80% of current Gallery users, and to include them 'better'. The corollary is that it's an explicit, accepted, result that (again, at a guess) 20% of current G2 users will find that their must-have features are simply *not* included in the team-written-and-supported code, and that they will have to either continue with G2 until somebody else includes the feature they want in G3, or possibly forever. Or if they have reasons for wanting to stop using G2, find another solution.
That debate was held and finished some months ago, before development of G3 started, and while everyone who comes new to the discussion has their own view on it - that's essentially the position. But I think you can take it as given, understood, and accepted that some people will move away from Gallery project code (just as they already do for a variety of reasons), and also hoped that others will migrate towards it on the basis of the strength of the features and performance it offers.
Sure, I understand all that and accept that I've probably got a good few weeks of G2 -> G3 re-coding work to do somewhere along the line (as the saying goes "no gain without pain"
) Regardless, I think the architectural simplification of the Galley family is A Good Thing, and hopefully it will make my re-coding work some what easier.
But I was also making a subtler point. The G3 development does not happen within a static external environment - user needs and expectations evolve at a pace, as do the quality and functionality of competing solutions. This is particularly true of commercial hosted solutions. For example, it was not so long ago that people used the relatively small email accounts provided by their connectivity ISP (or nominally charged for by specialist server providers like myself). Today few ISPs bother to compete with the gigabytes of space and excellent web front-ends provided by Google / Yahoo / Hotmail (indeed BT Broadband in the UK dumped their own mail servers and now provide re-branded Yahoo accounts).
So ISTM likely that Flikr et al will continue to develop their offerings so as to progressively squeeze the bottom/middle-end market for own-server solutions like Gallery. That's fine because many higher-end pro / pro-am photographers will still want full control over their images & website... but their expectations are also evolving (way beyond just having a simpler API to code for), so G3 needs to be designed with the future needs of this group in mind. All I've seen in the G3 feature list thus far is a slimming down of existing G2 features - nothing really to write home about. The promise (which I don't doubt will be delivered) of better performance and less complication under the hood doesn't really cut the mustard for what will probably be an increasingly competitive product space.
Dominic
http://photographicon.com/
For better or worse, that categorically *isn't* the demographic that G3 is targeted at.
There are after all only just so many ways to store and display photographs! But one of the 'features' of G3 (although perhaps not explicitly listed) is a much more AJAXy, interactive, user interface which should be feel much more up-to-date than the very "web circa. 2002" Gallery2. That means it will measure up as a more attractive alternative to outside-hosted solutions such as Flickr et al than G2 does at present. If you've tried coding AJAX style interfaces in G2 you'll know that support for that at the framework level is somewhere between execrable and non-existent.
And as you will no doubt be aware, it's a goal of the project for the future for others (like you and me) outside of the development team to step up to the plate and contribute our own must-have features to take G3 in the directions we want - towards the "higher-end pro / pro-am photographers" if that's what we desire. And we'll have a better, simpler toolset in a new core to make those features not just as good as what you can get from Flickr, but better.
It's a brave strategy, and I'm looking forward to seeing how it works out.
That, I fear, is a big strategic mistake! The low-end has already gone to Flikr, and many high-end pros would even bother to look at community-driven open-source solutions... so if G3 ain't specifically targeted at the mid-band pro / pro-ams, then who exactly do the developers think will be using it?
That's certainly welcome - I've been using the G2 SVN codebase for some time, so have seen AJAX creep into various admin dialogues, although I've not experimented with it in my templates.
Very true... but as always time is the enemy... and it will only be worth the while of folk like me adding to the G3 toolset if we believe the end product is on a strategic path to long-term success...
Is that Yes Minister speak?... as in:
Jim Hacker MP: "Ah Humphrey, I'd just like to run my latest idea past you. We're going to throw away hundreds of thousands of hours of coding work - our own and the public's - in order to build something that performs better on slow systems (that fewer and fewer people are using), and simpler and more beautiful in places that few people look. And we're not even going to target it at the market that our policy people tell us are likely to be the future users. So what do you think... is it Knighthood material?"
Sir Humphrey Appleby: "Well that's very brave, Minister".
NB: clearly I'm exaggerating for satirical effect
Dominic
http://photographicon.com/
Might be. Might not. It's up to the core developers to decide who they're aiming at, and what features to implement. As I said, that debate was closed some time ago.
From the G3 pages of the codex: http://www.adamatorres.com/gallery-project/?page_id=138
Au contraire. It's only worth while me adding to the G3 toolset if G3 is a product I want to use, a feature I want is missing, and it's within my skills to provide it.
Besides, G3's not a commercial product that's going to be 'dropped' by management if it doesn't pull in sufficient customers, or if the company funding it has a swerve in strategy and decides to sell dishwashers instead. As long as the core developers are interested to write it then it has a future. As long as what they write is elegant enough to pull in outside coders too, then it has a rosy future. So if you are worried about "strategic path" then you should support whatever direction the core team are minded to take it, because it's their continued personal-time interest that we all need, first and foremost.
Agreed it might or might not be a mistake - only time will tell - but my gut feeling is still on the negative side. "Improving the user interface of an open source image gallery project" is a good piece of work, but doesn't seem to recognise that the identified primary personas are likely to also become targets for Flikr et al over the coming few years... and they will have far more monetary resources to muster than Gallery (although that by no means guarantees their success at Gallery's expense).
Shame I didn't hear about the discussions earlier as I have a lot to contribute, and some form on spotting trends for technical services. In the mid 1990's I and a few others tried to persuade Cix (our home BBS for about 5 years) that they needed to change their business model and build a licensable server technology because online forums were going to explode in popularity... they thought we were mad... I shudder to think how many phpBB installs there now are. In 2000 I started to develop a form of VPS with web control panel for the ISP I worked for, but was stymied because the rest of the management thought that few people really wanted to manage their own servers... guess what is now a huge global growth area.
Not so much Au contraire as complementaires... G3 will be the product I want to use if it's likely to satisfy my requirements for at least a couple of years (the work involved in migrating to it won't justify it otherwise and I will as a matter of course re-evaluate the competition before making the decision). If I go for it, then your criteria naturally follow on.
True... but Sourceforge is littered with once popular OS projects that now have a scant handful of users & developers because something better came along... I'd hate that to happen prematurely to Gallery (ie through correctable strategic error rather by reaching a more natural end of life-cycle).
Dominic
http://photographicon.com/
The impression I get of the Gallery team is that they know exactly what kind of project they want. If it turns out that the users for that project are better served elsewhere, I'm sure they'll be happy with that outcome. The purpose of Gallery *isn't* to have a lot of users and in changing times adjust itself to that end - it's to scratch a particular itch that exists in the collective mind of the team. It's not a popularity contest, it's a "your photos on your website" project.
Contributors always welcome - mainly the sleeves-rolled-up getting-stuck-in-writing-code-and-documentation kind (now that the time for strategy discussions is long finished): #gallery at irc.freenode.net is the place to go.
You can please some of the people all of the time...
Personally I think the Gallery team have taken a brave decision to produce a product that will achieve what I take to be the core objective when they started the project however many years ago. Yes, it's a step away from the all-singing all-dancing monolith that G2 has become. But let's remember that the function of a gallery is to serve images to surfers in a fast and efficient manner. Just about anything beyond that can be considered an optional extra. So if the developers make it easy for additional modules to plug into the gallery without needing to produce a massive core code, then they certainly get my vote.
Of course those modules do depend on a stable and well constructed core which is going to have a long shelf life in order to give third-party developers the incentive to write them. I'm sure this is a priority for the G3 team because it is such an important concept. Optional modules provide the range of pick and mix features which tailor Gallery to such a wide range of needs and give users the ability to decide if they want a small, basic and presumably faster install, or if they want the all-singing, all-dancing version with it's inevitable server overheads.
My personal opinion is that options such as e-commerce should be available as paid rather than free plugins because they move away from the concept of Gallery as a way to serve images in an open and free environment and towards Gallery as a premium commercial offering of the likes of ImageFolio. No doubt I'll get put down for such a suggestion but then my opinion and a dollar get me a ticket to the lottery ;)
Another such opinion mirrors one I've seen mentioned here several times. I do believe that taking a few more months on the development time and adding a database abstraction layer will save a lot of potential problems and go some way to pacify the IIS users. Even if the first release still supports only mySQL5, the code would be in place to add further support at a later date without upsetting anything else.
No I don't use IIS myself. I also don't use a 2/5 server though no doubt there will be an upgrade from the current mySQL4.3 at some stage and I accept that as a condition of being able to use G3 when it ships. Until then I'll keep using 2.3. I'm not paying for it, except by a desire to send a donation when I am able, so I don't feel any solid ground beneath me upon which to make demands of those who provide such a fantastic product without requiring even a token payment.
It's your baby and while I can express a 'wish' that there is an easy to use method to transfer files and custom text/comments from 2.3 to 3.X on installation, I just don't think I have the right to do more than show support for those who dedicate so much time to making a major free and open-source script available.
Unfortunately my best asset here is precisely the strategic thinking and analysis that now seems to be falling on a closed debate. I was once a pro assembly language coder back in the days when Z80's were cool, but now only code out of necessity (much as I really love the art). Regrettably I have no time for speculatively working on things that I'm a long way from putting to use, so I shall bow out for now.
And of course I know none of you do this as popularity contest - we're all here because we want to create the very best of breed tools to help us individually with the stuff we do... none-the-less, what I have said should be given more than just cursory attention. Anyway it's been good talking to you, and I wish you and the rest of the team the very best of successes for the "brave strategy"
Dominic
http://photographicon.com/
Just to be clear, I'm not part of the team, just a committed G2 user and contributor. I'm only commenting as a bystander and occasional participant (and from an external perspective) in the debate about what G3 should be, which we had a few months ago.
This is a great discussion and I'm happy to say that alecmyers is doing a great job of representing the opionion of the Gallery dev team.
@Photographicon: We can't make a strategic decision based on your gut opinion. This project has very high costs (in both cash and time). If you feel that we're headed in the wrong direction, please contribute some of your time and do some research and give us some *data*. Otherwise, my gut opinion trumps yours since a) I've been doing it longer and b) I'm the one actually investing the time into it.
@Rhyull: I think we're in agreement in most places, but I wanted to pick on one thing that you mention. A database abstraction layer is not a magic wand that we can wave over the code to make it compatible across the board. G3 is based on Kohana which has a database abstraction layer, and is cross-platform aware. But you still have to do a lot of work to make it stable and reliable on these platforms. It takes time to write flexible code, make it robust, analyze it for security flaws, and document. Every database we support adds to the burden across the board. Every platform we support adds to the burden across the board. Taking "a few more months" is a huge burden when you consider that the projected entire development cycle for G3 is 3 months to begin with.
We are going to keep this small and tightly scoped and as a result you'll have a new product that you can use starting on February 1st.
Cool... I pay attention to my gut feelings because they prompt a pause for thought. But I'd be seriously worried by anyone who radically changed direction just based on a few paragraphs typed from the top of my head! Now that I know the debate may not be so closed as it first appeared, I'll try to find some time to evidence my thoughts and write you something more coherent.
To paraphrase something I PMed to alecmyers: Don't get me wrong, I'm not arguing against G3 per se... I just think (from what I've gleaned so far) that it's concentrating too much on a market segment that's clearly going to ebb away during its life time. Perhaps what I'm really arguing for is G4, brother of G3, aimed more at the needs of professional users. Perhaps they are even the same thing... until there's some useable code, we won't know.
Dominic
http://photographicon.com/
Speaking as a 'professional' user, my requirements aren't orthogonal to those of the 'non-professional' user. In fact, if anything, the length of my requirements list is shorter because I explicitly don't want (and would remove) all the bells, whistles, fancies, gimicks, tricks, maps, animations, iconpacks, clouds, feeds and features EXCEPT the very few that support the absolute primary purpose of my website. If I represent any class of user at all, it's the class that is never going to be swayed towards Gallery by, for instance, the ability to upload from my mobile phone, or geotag my pictures, or embed in Joomla, or whatever. From my perspective, then, the fact that the Gallery Team is dedicated its G3 time *not* to implementing such things but instead to building a stronger core (to which the very few extras I want can be added) is a win for me. Instead of making use of 30% of their work (as with G2) I can use 90%, and add a little of my own - hopefully to come with something much stronger.
All G3 needs is the flexibility to add those extra features at some time in the future. Naturaly I can't speak for other's "must haves", but I'm happy to say that whenever I've been in doubt as to whether that flexibility has been included in a direction that I'm concerned about, and I've queried the point, the answer has always been a fairly clear "yes".
So just because G3 as planned for release on 1 Feb doesn't explicit aim to support pro users and the features they (we) want, doesn't mean we have to write it off in favour of "G4" just yet.
Good luck guys! I'm sure the decision to do a total rewrite was not made lightly, and I wish you all the best.
As an IIS user who is not prepared to migrate to Apache just for G3, I obviously have a few concerns. I suspect though that this might be more of a matter of understanding the intent of the comment about only developing for Apache.
Do the development team intend to develop G3 to utilise specific functionality that is only present on Apache, or do you simply mean that you won't be coding in any workarounds for specific platforms (e.g. ISAPI Rewrite 2 clean URL's)?
There is a very important difference here as PHP is designed (more or less) to be a platform independent language. Meaning that unless G3 is going to be designed specifically to utilise the Apache architecture then ideally it should be able to run on any platform capable of processing PHP scripts.