gallery-devel — Discussion on development directions, proposed features, implementation details.

[Gallery-devel] Fwd: [Gallery-core] Taking over the Gallery project

[Bharat M. <bh...@me...>]

Context: Gallery is going into hibernation, details are here:
http://galleryproject.org/time-to-hibernate

Several folks emailed me directly about taking over the project. I started
a thread with them and cc'd the gallery-core mailing list. I'm going to cc'
in the gallery-devel mailing list to get a broader audience (and also
because this list is publicly archived whereas gallery-core is not). Here's
the back conversation, I'll cc the rest of the discussion here next.

Forwarded conversation
Subject: Taking over the Gallery project
------------------------

From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 9:26 AM
To: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


(cc: gallery-core team, please cc this list on all replies. It's moderated,
but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 9:45 AM
To: Bharat Mediratta <bh...@me...>, Michael Otteneder <
m.o...@gm...>, Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


 Hi guys,

I am available at Skype. My nick is 'koelnkalk'

Lets collect ideas and present them to Bharat. Important is that the
community not just sees things are going on but improve. That will be the
main task in my opinion.

Looking forward hearing from you!

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project


----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 10:16 AM
To: Bharat Mediratta <bh...@me...>


 Hi,

My messages got rejected by the list.

So you mean, we build up sort of a temporary fork and see how well it is
going?

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project

 (cc: gallery-core team, please cc this list on all replies. It's
moderated, but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 10:21 AM
To: Markus Bopp <mar...@cr...>



Sorry about that - I've turned off the moderation for the mailing list for
now. Can you please try again?

I see you asked a question but I'd prefer to answer it on the thread with
everybody so that we don't leave folks out. Can you re-ask it publicly?
thanks!

----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 10:26 AM
To: Markus Bopp <mar...@cr...>, Bharat Mediratta <
bh...@me...>, Michael Otteneder <m.o...@gm...>, Matthew
Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


  ------------------------------
Von: Markus Bopp <mar...@cr...>
Gesendet: ‎27.‎06.‎2014 18:46
An: Bharat Mediratta <bh...@me...>; Michael Otteneder
<m.o...@gm...>; Matthew Mellon <mel...@gm...>

Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: AW: Taking over the Gallery project

 Hi guys,

I am available at Skype. My nick is 'koelnkalk'

Lets collect ideas and present them to Bharat. Important is that the
community not just sees things are going on but improve. That will be the
main task in my opinion.

Looking forward hearing from you!

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project

 (cc: gallery-core team, please cc this list on all replies. It's
moderated, but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Matthew Mellon* <mel...@gm...>
Date: Fri, Jun 27, 2014 at 11:08 AM
To: Bharat Mediratta <bh...@me...>
Cc: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Gallery Project Core Team discussion list <
gal...@li...>


Hello all,

Thanks for offers to keep the project going, and thank you Bharat for you
very reasoned approach to it all.

I agree that your brand should survive this and any future transition, and
have been wondering what kind of formal organization method and charter
could best facilitate that for what is inherently an international
project.

In the U.S., a non-profit organization would typically organize by filing
paperwork to receive a tax ID number, which is used in filing annual forms
that I can think summarizes the year's ledger and any accounts (if handling
any actual money, if necessary, for covering operating costs, if there
are/were any -- there may not need to be).  A charter would be written to
organize the governance of such an organization, and if any funds are
involved, the first treasurer would open a bank account and upon voting to
change out leadership, the old account is closed and a new account opened
by the new treasurer.  The charter would dictate things like how decisions
are made, core mission/direction and anything that survives in perpetuity,
like code remaining open source, the "trademark" but license to use the
"brand" and logo, etc.

That's potentially getting a little ahead of things, but I wanted to offer
what I knew so far, as my wife recently did some work to found a local
chapter of a larger organization, so we've learned a bit already.  I'm
certain I have much more to learn.  I must confess to being newer to
development (though I've modified small amounts of core code and numerous
modules, both for Gallery 2 and 3), but not so new to project management
and remote asynchronous collaboration.  I feel that my challenge would be
to keep abreast of the many PHP-related security advisories that come out
and ensure that the code base remains secure (and ideally that any
co-hosted modules do as well).

I always welcome other suggestions, and am quite certain that you both,
independently and collectively, will have more experience with code
development than I.  As I have occasionally been known to say, "I'm an
expert in nothing, but give me an hour...."  I'm always happy to help.

A bit about myself:  my work in graduate school (geology) centered on
ancient climate reconstruction; I managed hazardous waste sites for 10
years (overseeing investigations and cleanup work); I designed and
implemented methods and systems designed to get data on-screen and in 3-D
more rapidly than before (minutes instead of months); I implemented an
enterprise-wide LDAP-enabled secure Gallery 2 internal site, now being
replaced by Gallery 3, as a repository for all photographic records, many
of which support court cases (thus, EXIF metadata, security, "keep
original" and OpenSearch accessibility are key features); I have recently
implemented a few systems now in use agency-wide for the automated
discovery and preservation of data, and upgrade of the OS on 24,000 PCs
(throughout a U.S. Government agency, which I do not in any way represent
here -- this email account is solely used for personal interests).  For the
internal Gallery implementation, I wrote scripts and procedures used by
contractors to perform time-corrections and geotagging on photos "safely"
offloaded from camera cards (never via drag-and-drop, as this alters
filesystem metadata) and which call EXIFtool to embed photographer and
copyright holder into the EXIF/IPTC metadata prior to upload to Gallery.
Therein, the "virtual link" of one photo to multiple galleries (in v2) was
useful to ensure "single-instance storage", as is the de-duplication module
in Gallery 3 (alerting of duplicates on upload and offereing a delete
button).  I modified User Albums to cleanly organize and create user
albums, delegated administration to a group, who for example, create shared
Group albums for shared events where multiple cameras (all time
synchronized via the aforementioned script/process) all upload in a sane
fashion for a single event in an event category.  The Gallery 3
imlementation just got close to fully live this week, with PAM/ADldap for
account creation, User Albums to create their own albums, and SSO to
prevent password challenges thereafter (I wish I didn't store any
passwords, but I may get there).  Obviously, with the geotagging, the
EXIFgps module (map display and manual geotagging) is important as well,
since all of our inspection/oversight photos are taken somewhere.  At
present, I have a team of three contractors assisting with the management
of Gallery.  I have a few actual developers, accessible too, though I'm
uncertain of their actual usefulness just yet.  (A good friend is a popular
Lynda.com instructor of both PHP and GIT, but his preferred platform for
his development company is Ruby-on-Rails -- I still lean on him once in a
while though.)

I've been kicking around the notion of hosting code on code.google.com
(git), and transitioning forums (if desirable/advantageous) to something
like Google Groups, but I'd have to revisit what I recall of both before
actually recommending either.  I do have a Skype account (somewhere -- have
to dust that off or start another), obviously a Google account, am quite
familiar with Linux, VMs, and have built a great many test VMs for code and
system evaluation.

As for my interest in Gallery, I chose it for our implementation because it
is unmatched in terms of security (if implemented carefully),
delegation/collaboration, multi-user accessibility and data integrity for
large-scale photo management.  I've revisited that decision every six
months for several years now, and it's always been the clear leader.

Hope that helps you all figure out if I would be potentially useful, and
perhaps stirs some thoughts about how to meet Bharat's long-term or
perpetual goals.  (I would bet there is a way for you, Bharat, to retain or
defend overall use and governance of "brand", while still having delegated
the ongoing administration/management.  Would have to look into that.  The
FSF may have some stock drafts for charters, which might be a good starting
point, or at least some effective examples to start with.)

I'm off to pickup a guest flying in from England today, but if Skype can
call an actual phone number, I'm happy to share it.  I've got an hour of
sitting in the car (starting in 10 minutes).  Google "Hangouts" are also
easy to set up (I'm not an overzealous Google fan, by the way, but I do
like free and effective collaboration tools).


Many thanks again,

--Matt Mellon
 mel...@gm...
 (Philadelphia, PA, USA)


----------
From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 12:15 PM
To: Matthew Mellon <mel...@gm...>
Cc: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Gallery Project Core Team discussion list <
gal...@li...>



Just a quick note to say that Gallery already has a non-profit arm set up
under http://www.spi-inc.org/ to handle tax-deductible donations. We also
have a decent sized war chest and a revenue stream which will keep the
lights on for the servers indefinitely.

----------
From: *Matthew Mellon* <mel...@gm...>
Date: Fri, Jun 27, 2014 at 12:57 PM
To: Bharat Mediratta <bh...@me...>
Cc: Michael Otteneder <m.o...@gm...>, Gallery Project Core Team
discussion list <gal...@li...>, Markus Bopp <
mar...@cr...>


Thanks.  That is great to hear.  Just read through their services and
relationships docs.  Looks like the section on intangible assets could
apply to the trademark (if any, "branding" if not).

----------
From: *Bharat Mediratta* <bh...@me...>
Date: Sat, Jun 28, 2014 at 4:16 PM
To: ju...@th...



(Justin - here's the conversation we've had so far, I'll cc' you into the
discussion)

Forwarded conversation
Subject: Taking over the Gallery project
------------------------

From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 9:26 AM
To: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


(cc: gallery-core team, please cc this list on all replies. It's moderated,
but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 9:45 AM
To: Bharat Mediratta <bh...@me...>, Michael Otteneder <
m.o...@gm...>, Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


 Hi guys,

I am available at Skype. My nick is 'koelnkalk'

Lets collect ideas and present them to Bharat. Important is that the
community not just sees things are going on but improve. That will be the
main task in my opinion.

Looking forward hearing from you!

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project


----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 10:16 AM
To: Bharat Mediratta <bh...@me...>


 Hi,

My messages got rejected by the list.

So you mean, we build up sort of a temporary fork and see how well it is
going?

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project

 (cc: gallery-core team, please cc this list on all replies. It's
moderated, but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 10:21 AM
To: Markus Bopp <mar...@cr...>



Sorry about that - I've turned off the moderation for the mailing list for
now. Can you please try again?

I see you asked a question but I'd prefer to answer it on the thread with
everybody so that we don't leave folks out. Can you re-ask it publicly?
thanks!

----------
From: *Markus Bopp* <mar...@cr...>
Date: Fri, Jun 27, 2014 at 10:26 AM
To: Markus Bopp <mar...@cr...>, Bharat Mediratta <
bh...@me...>, Michael Otteneder <m.o...@gm...>, Matthew
Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>


  ------------------------------
Von: Markus Bopp <mar...@cr...>
Gesendet: ‎27.‎06.‎2014 18:46
An: Bharat Mediratta <bh...@me...>; Michael Otteneder
<m.o...@gm...>; Matthew Mellon <mel...@gm...>

Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: AW: Taking over the Gallery project

 Hi guys,

I am available at Skype. My nick is 'koelnkalk'

Lets collect ideas and present them to Bharat. Important is that the
community not just sees things are going on but improve. That will be the
main task in my opinion.

Looking forward hearing from you!

Regards,
Markus
 ------------------------------
Von: Bharat Mediratta <bh...@me...>
Gesendet: ‎27.‎06.‎2014 18:27
An: Michael Otteneder <m.o...@gm...>; Markus Bopp
<mar...@cr...>; Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list
<gal...@li...>
Betreff: Taking over the Gallery project

 (cc: gallery-core team, please cc this list on all replies. It's
moderated, but I'll approve your mails)

Michael, Markus, Matthew -

Thank you for offering to continue development on Gallery. I'm excited to
see somebody take it over and do good things with it. The source code for
Gallery is freely available on github and Sourceforge so it's easy to find
and work with it. I would love to see somebody continue to move it forward.

The tricky part is how to manage the brand. I can't simply turn the Gallery
brand and community over to a team that I don't know. I have too much
invested in it and there's too much community good will at stake. I would
*love* to turn the community over to a team that I know will care for it
and treat it with respect - but I don't have an easy way to determine who
that team is going to be.

As such, if you guys are interested I suggest you coordinate with one
another and come up with a plan for how you'd like to proceed. It doesn't
make a lot of sense to compete with each other. Then I need to see some
development and improvement of the project over a sustained period of time
before I'm willing to turn the website and brand over to you.

For now I'm going to continue to mothball the website but I'll keep it
running and if you come up with a plan I'll be happy to steer users your
way to give you enough fuel to keep the project moving forward.

Let me know what you decide.

regards,
-Bharat

----------
From: *Matthew Mellon* <mel...@gm...>
Date: Fri, Jun 27, 2014 at 11:08 AM
To: Bharat Mediratta <bh...@me...>
Cc: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Gallery Project Core Team discussion list <
gal...@li...>


Hello all,

Thanks for offers to keep the project going, and thank you Bharat for you
very reasoned approach to it all.

I agree that your brand should survive this and any future transition, and
have been wondering what kind of formal organization method and charter
could best facilitate that for what is inherently an international
project.

In the U.S., a non-profit organization would typically organize by filing
paperwork to receive a tax ID number, which is used in filing annual forms
that I can think summarizes the year's ledger and any accounts (if handling
any actual money, if necessary, for covering operating costs, if there
are/were any -- there may not need to be).  A charter would be written to
organize the governance of such an organization, and if any funds are
involved, the first treasurer would open a bank account and upon voting to
change out leadership, the old account is closed and a new account opened
by the new treasurer.  The charter would dictate things like how decisions
are made, core mission/direction and anything that survives in perpetuity,
like code remaining open source, the "trademark" but license to use the
"brand" and logo, etc.

That's potentially getting a little ahead of things, but I wanted to offer
what I knew so far, as my wife recently did some work to found a local
chapter of a larger organization, so we've learned a bit already.  I'm
certain I have much more to learn.  I must confess to being newer to
development (though I've modified small amounts of core code and numerous
modules, both for Gallery 2 and 3), but not so new to project management
and remote asynchronous collaboration.  I feel that my challenge would be
to keep abreast of the many PHP-related security advisories that come out
and ensure that the code base remains secure (and ideally that any
co-hosted modules do as well).

I always welcome other suggestions, and am quite certain that you both,
independently and collectively, will have more experience with code
development than I.  As I have occasionally been known to say, "I'm an
expert in nothing, but give me an hour...."  I'm always happy to help.

A bit about myself:  my work in graduate school (geology) centered on
ancient climate reconstruction; I managed hazardous waste sites for 10
years (overseeing investigations and cleanup work); I designed and
implemented methods and systems designed to get data on-screen and in 3-D
more rapidly than before (minutes instead of months); I implemented an
enterprise-wide LDAP-enabled secure Gallery 2 internal site, now being
replaced by Gallery 3, as a repository for all photographic records, many
of which support court cases (thus, EXIF metadata, security, "keep
original" and OpenSearch accessibility are key features); I have recently
implemented a few systems now in use agency-wide for the automated
discovery and preservation of data, and upgrade of the OS on 24,000 PCs
(throughout a U.S. Government agency, which I do not in any way represent
here -- this email account is solely used for personal interests).  For the
internal Gallery implementation, I wrote scripts and procedures used by
contractors to perform time-corrections and geotagging on photos "safely"
offloaded from camera cards (never via drag-and-drop, as this alters
filesystem metadata) and which call EXIFtool to embed photographer and
copyright holder into the EXIF/IPTC metadata prior to upload to Gallery.
Therein, the "virtual link" of one photo to multiple galleries (in v2) was
useful to ensure "single-instance storage", as is the de-duplication module
in Gallery 3 (alerting of duplicates on upload and offereing a delete
button).  I modified User Albums to cleanly organize and create user
albums, delegated administration to a group, who for example, create shared
Group albums for shared events where multiple cameras (all time
synchronized via the aforementioned script/process) all upload in a sane
fashion for a single event in an event category.  The Gallery 3
imlementation just got close to fully live this week, with PAM/ADldap for
account creation, User Albums to create their own albums, and SSO to
prevent password challenges thereafter (I wish I didn't store any
passwords, but I may get there).  Obviously, with the geotagging, the
EXIFgps module (map display and manual geotagging) is important as well,
since all of our inspection/oversight photos are taken somewhere.  At
present, I have a team of three contractors assisting with the management
of Gallery.  I have a few actual developers, accessible too, though I'm
uncertain of their actual usefulness just yet.  (A good friend is a popular
Lynda.com instructor of both PHP and GIT, but his preferred platform for
his development company is Ruby-on-Rails -- I still lean on him once in a
while though.)

I've been kicking around the notion of hosting code on code.google.com
(git), and transitioning forums (if desirable/advantageous) to something
like Google Groups, but I'd have to revisit what I recall of both before
actually recommending either.  I do have a Skype account (somewhere -- have
to dust that off or start another), obviously a Google account, am quite
familiar with Linux, VMs, and have built a great many test VMs for code and
system evaluation.

As for my interest in Gallery, I chose it for our implementation because it
is unmatched in terms of security (if implemented carefully),
delegation/collaboration, multi-user accessibility and data integrity for
large-scale photo management.  I've revisited that decision every six
months for several years now, and it's always been the clear leader.

Hope that helps you all figure out if I would be potentially useful, and
perhaps stirs some thoughts about how to meet Bharat's long-term or
perpetual goals.  (I would bet there is a way for you, Bharat, to retain or
defend overall use and governance of "brand", while still having delegated
the ongoing administration/management.  Would have to look into that.  The
FSF may have some stock drafts for charters, which might be a good starting
point, or at least some effective examples to start with.)

I'm off to pickup a guest flying in from England today, but if Skype can
call an actual phone number, I'm happy to share it.  I've got an hour of
sitting in the car (starting in 10 minutes).  Google "Hangouts" are also
easy to set up (I'm not an overzealous Google fan, by the way, but I do
like free and effective collaboration tools).


Many thanks again,

--Matt Mellon
 mel...@gm...
 (Philadelphia, PA, USA)


----------
From: *Bharat Mediratta* <bh...@me...>
Date: Fri, Jun 27, 2014 at 12:15 PM
To: Matthew Mellon <mel...@gm...>
Cc: Michael Otteneder <m.o...@gm...>, Markus Bopp <
mar...@cr...>, Gallery Project Core Team discussion list <
gal...@li...>



Just a quick note to say that Gallery already has a non-profit arm set up
under http://www.spi-inc.org/ to handle tax-deductible donations. We also
have a decent sized war chest and a revenue stream which will keep the
lights on for the servers indefinitely.

----------
From: *Matthew Mellon* <mel...@gm...>
Date: Fri, Jun 27, 2014 at 12:57 PM
To: Bharat Mediratta <bh...@me...>
Cc: Michael Otteneder <m.o...@gm...>, Gallery Project Core Team
discussion list <gal...@li...>, Markus Bopp <
mar...@cr...>


Thanks.  That is great to hear.  Just read through their services and
relationships docs.  Looks like the section on intangible assets could
apply to the trademark (if any, "branding" if not).



----------
From: *Bharat Mediratta* <bh...@me...>
Date: Sat, Jun 28, 2014 at 4:17 PM
To: Matthew Mellon <mel...@gm...>
Cc: Michael Otteneder <m.o...@gm...>, Gallery Project Core Team
discussion list <gal...@li...>, Markus Bopp <
mar...@cr...>, ju...@th...



cc: Justin Goetz

----------
From:  <ju...@th...>
Date: Sat, Jun 28, 2014 at 6:46 PM
To: Bharat Mediratta <bh...@me...>


 Mr. Mediratta,
Thank you for your response. I can completely understand why you
wouldn't want to just hand over the brand.
And to be quite honest, I've been talking to a lot of our members
recently, and I feel like this might just be a bit to much for

us to take on with the current amount of PHP Devs we have. I wouldn't
want to see something happen to the
project simply because we are still a small community and wouldn't
have the support. Sorry if I did take your time,

but if you do ever need server support or if you can find some way
that we can help please do email me.
I'll be interested in supporting the project as much as I can.

Best of luck,
Justin Goetz.


----------
From: *Dave Moore* <da...@la...>
Date: Sat, Jun 28, 2014 at 7:09 PM
To: Gallery Project Core Team discussion list <
gal...@li...>, Markus Bopp <mar...@cr...>,
Bharat Mediratta <bh...@me...>, Michael Otteneder <
m.o...@gm...>, Matthew Mellon <mel...@gm...>


 I'm available to still continue in the roll that I have been doing over
the years.

Dave Moore (floridave)
780 902 7394 Mountain time.

Cheers!

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awardshttp://p.sf.net/sfu/Bonitasoft



_______________________________________________
Gallery-core mailing
lis...@li...://lists.sourceforge.net/lists/listinfo/gallery-core



----------
From: *Matthew Mellon* <mel...@gm...>
Date: Sat, Jun 28, 2014 at 7:34 PM
To: Dave Moore <da...@la...>
Cc: Michael Otteneder <m.o...@gm...>, Bharat Mediratta <
bh...@me...>, Markus Bopp <mar...@cr...>, Gallery Project
Core Team discussion list <gal...@li...>


That is a tremendously reassuring thing to hear (whatever role I might
have).  Have read many of your helpful posts.

----------
From: *Markus Bopp* <mar...@cr...>
Date: Mon, Jun 30, 2014 at 4:32 AM
To: Bharat Mediratta <bh...@me...>


Hi @all,

we started to fork Gallery3 and created a new github repo for Gallery2.

We just had our mondays meeting and decided to start with the fork approach
and compare both versions with each other as well as if there needs to be
some urgent patched being added that can be re-contributed (to keep the
ball running).

However, it would be great to provide us with some insight about the most
urgent known bugs/issues that need be fixed. Otherwise we’ll try to get
along what is openly available.
We also can start to give some support to users from our spare time. Is it
possible to do that through the project site or is better to use our forums
temporarily? If we use our infrastructure, then please let the community
know about it once we are ready (someday this week).

Finally, we outlined a possible technical approach on how to continue with
the project:

V 2.x is still widely used due to its larger amount of features. Therefore
we think a good idea is to officially extend that version’s lifetime but no
further feature requests will be accepted (only fixes).
In the meanwhile, version 3x will be degraded to a “beta” where we will
over time transfer missing features from 2.x. Important is not to confuse
the community with decisions like this. So it needs a well thought and
coordinated post at the main project site, such that people see nothing
stops here, it’s just a new beginning. That statement should be made soon.

Timeline for this still depends on our research this week, but from what we
can see, a lot can be done already this year.

Long term approaches, and that is what could make this project ahead of
others, is moving to the multichannel-approach with all its implications
(mobile devices, cloud storages, etc).
But that’s future talk. For now we are focusing to keep the motor running.

About non-profit organizations, I can’t tell much as we are a german
company but I think everything should stay as it is if there is already a
non-profit setup implemented and working well.
Important is to have people from the states involved in things like
treasury as it might keep things easier, as non-us organizations like us
don’t have much clue about us-laws.

Anyhow, I see us more at the technical / support part anyway.

Regards,
Markus

----------
From: *Markus Bopp* <mar...@cr...>
Date: Mon, Jun 30, 2014 at 4:33 AM
To: Matthew Mellon <mel...@gm...>
Cc: Gallery Project Core Team discussion list <
gal...@li...>, Michael Otteneder <
m.o...@gm...>


Hi @all,

we started to fork Gallery3 and created a new github repo for Gallery2.

We just had our mondays meeting and decided to start with the fork approach
and compare both versions with each other as well as if there needs to be
some urgent patched being added that can be re-contributed (to keep the
ball running).

However, it would be great to provide us with some insight about the most
urgent known bugs/issues that need be fixed. Otherwise we’ll try to get
along what is openly available.
We also can start to give some support to users from our spare time. Is it
possible to do that through the project site or is better to use our forums
temporarily? If we use our infrastructure, then please let the community
know about it once we are ready (someday this week).

Finally, we outlined a possible technical approach on how to continue with
the project:

V 2.x is still widely used due to its larger amount of features. Therefore
we think a good idea is to officially extend that version’s lifetime but no
further feature requests will be accepted (only fixes).
In the meanwhile, version 3x will be degraded to a “beta” where we will
over time transfer missing features from 2.x. Important is not to confuse
the community with decisions like this. So it needs a well thought and
coordinated post at the main project site, such that people see nothing
stops here, it’s just a new beginning. That statement should be made soon.

Timeline for this still depends on our research this week, but from what we
can see, a lot can be done already this year.

Long term approaches, and that is what could make this project ahead of
others, is moving to the multichannel-approach with all its implications
(mobile devices, cloud storages, etc).
But that’s future talk. For now we are focusing to keep the motor running.

About non-profit organizations, I can’t tell much as we are a german
company but I think everything should stay as it is if there is already a
non-profit setup implemented and working well.
Important is to have people from the states involved in things like
treasury as it might keep things easier, as non-us organizations like us
don’t have much clue about us-laws.

Anyhow, I see us more at the technical / support part anyway.

Regards,
Markus

———
Software-Developer

Crosstec GmbH & Co. KG
Hohenzollernring 57
D-50672 Köln

Telefon: +49 (0) 221 30060654
Fax: +49 (0) 3212 1379723

E-Mail: in...@cr...
Internet: www.crosstec.de

Registergericht: Amtsgericht Köln
Registernummer: HRA 28580

Persönlich haftende Gesellschafterin:
CROSSTEC Verwaltungs-GmbH

Registergericht: Amtsgericht Köln
Registernummer: HRB 72959
Vertretungsberechtigter Geschäftsführer: Markus Bopp

Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz:
DE281597905

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Gallery-core mailing list
Gal...@li...
https://lists.sourceforge.net/lists/listinfo/gallery-core

Re: [Gallery-devel] REST image upload fails

[Dennis R. <den...@gm...>]

Hi Markus,

many thanks for your reply. I've suspected something like this :-/ -> Thus
I need access to the server to see what's going wrong there.

Anyways, thanks for your hints. Hopefully it is just the missing REST API -
press thumb!


cheers
Dennis


2013/11/6 Markus Illenseer <ma...@ma...>

>
>  But now one customer/tester has the problem, that the upload request
>> returns the following response:
>>
>> HTTP/1.1 500 Internal Server Error
>> Date: Wed, 06 Nov 2013 16:28:48 GMT
>> Server: Apache
>> Accept-Ranges: bytes
>> Content-Type: text/html
>> Connection: close
>> <!-- SHTML Wrapper - 500 Server Error -->
>>
>>
>>
>> Does somebody has any idea what's the problem here?
>>
>
> Either Apache-Log or php-Log will tell more about the Error 500.
> Eventually you need to set php.ini to verbose error outputs (and restart
> Apache).
>
> My guess: the rest-API is missing?
>
> --
> Markus Illenseer
>

Re: [Gallery-devel] REST image upload fails

[Markus I. <ma...@ma...>]

> But now one customer/tester has the problem, that the upload request returns the following response:
>
> HTTP/1.1 500 Internal Server Error
> Date: Wed, 06 Nov 2013 16:28:48 GMT
> Server: Apache
> Accept-Ranges: bytes
> Content-Type: text/html
> Connection: close
> <!-- SHTML Wrapper - 500 Server Error -->
>
>
>
> Does somebody has any idea what's the problem here?

Either Apache-Log or php-Log will tell more about the Error 500. 
Eventually you need to set php.ini to verbose error outputs (and restart 
Apache).

My guess: the rest-API is missing?

--
Markus Illenseer

[Gallery-devel] REST image upload fails

[Dennis R. <den...@gm...>]

Hi guys, 

in iGallery3 you've also the possibility to upload images in your gallery3 installation. 

But now one customer/tester has the problem, that the upload request returns the following response: 

HTTP/1.1 500 Internal Server Error
Date: Wed, 06 Nov 2013 16:28:48 GMT
Server: Apache
Accept-Ranges: bytes
Content-Type: text/html
Connection: close
<!-- SHTML Wrapper - 500 Server Error -->



Does somebody has any idea what's the problem here?


cheers
Dennis

Re: [Gallery-devel] iOS gallery3 client

[Bharat M. <bh...@me...>]

Hey Dennis - I'm not using iOS currently but this sounds really cool.  Not
sure how many folks on this list use iOS, but if you want to get a broader
distribution of testers we'd be happy to feature this on the website.  Let
me know if you're interested.


On Wed, Oct 23, 2013 at 11:12 PM, Dennis Rochel <den...@gm...>wrote:

> Dear gallery community,
>
> I'm the developer of iGallery, a gallery2 client for iOS devices. As some
> of you noticed, the client is very outdated, and thus it is time for
> something new. I've developed iGallery3 over the last two years as a
> personal project/hobby, and now it is nearly finished.
>
> Thus I want to ask if somebody here in this community is interested in
> joining a beta test, to push the quality of this app a little bit;-).
>
>
> Some facts:
>
> Supported Protocol: gallery3 REST API
>
> Supported devices: iPhone 4S, iPhone 5, iPhone 5C, iPhone 5S
>
> Supported iOS Version: iOS7
>
>
> It is an universal App, thus it is also working with a nice interface on
> iPads, but I will first release the iPhone/iPod version and then the iPad
> version - just to minimize the trouble spots.
>
> I also uploaded a few screenshots, that you can decide if you want to join
> the beta test.
>
> http://gallery.imount.de/Sonstiges/iGallery3
>
> If you want to join the test please answer on this post or send me an
> email to:
>
> den...@gm...
>
> At this point I also want to say thanks to the gallery1/2/3 developer
> team. I'm using this pice of software for round about 10 years, and I''m
> totally happy with the intuitive way to manage my 35.756 images and videos,
> especially with the possibility to access them from everywhere.
>
>
> cheers from Germany
>
> Dennis
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

[Gallery-devel] iOS gallery3 client

[Dennis R. <den...@gm...>]

Dear gallery community,

I'm the developer of iGallery, a gallery2 client for iOS devices. As some
of you noticed, the client is very outdated, and thus it is time for
something new. I've developed iGallery3 over the last two years as a
personal project/hobby, and now it is nearly finished.

Thus I want to ask if somebody here in this community is interested in
joining a beta test, to push the quality of this app a little bit;-).


Some facts:

Supported Protocol: gallery3 REST API

Supported devices: iPhone 4S, iPhone 5, iPhone 5C, iPhone 5S

Supported iOS Version: iOS7


It is an universal App, thus it is also working with a nice interface on
iPads, but I will first release the iPhone/iPod version and then the iPad
version - just to minimize the trouble spots.

I also uploaded a few screenshots, that you can decide if you want to join
the beta test.

http://gallery.imount.de/Sonstiges/iGallery3

If you want to join the test please answer on this post or send me an email
to:

den...@gm...

At this point I also want to say thanks to the gallery1/2/3 developer team.
I'm using this pice of software for round about 10 years, and I''m totally
happy with the intuitive way to manage my 35.756 images and videos,
especially with the possibility to access them from everywhere.


cheers from Germany

Dennis

Re: [Gallery-devel] ORM_MPTT_Core function parents() -> mysql not using index

[Bharat M. <bh...@me...>]

cc: gallery-devel

I'm up to my ears right now - I'll get to this when I can (but it might be
a while).  You might considering asking in the forums...


On Thu, Aug 15, 2013 at 8:12 AM, Adrian <ad...@ya...> wrote:

> Hi, I'm sorry to bother you with this but I think you are the only one
> capable to help me.
>
> I find this in class ORM_MPTT_Core:
>   function parents() {
>     return $this
>       ->where("left_ptr", "<=", $this->left_ptr)
>       ->where("right_ptr", ">=", $this->right_ptr)
>       ->where("id", "<>", $this->id)
>       ->order_by("left_ptr", "ASC")
>       ->find_all();
>   }
>
> I'm using gallery 3 and it seems that mysql 5.1.30 is not using any index
> when executing the query generated by function parents(). I'd like to FORCE
> INDEX with mysql how would I do this ?
>
> thank you in advance
>
>
> *Adrian **Petre* (PMP certified)
> mail:    ad...@ya...
> phone: +04 0724 234 095
>

Re: [Gallery-devel] G3.1 - pagination module removal?

[Bharat M. <bh...@me...>]

Make it so!


On Thu, Jul 4, 2013 at 1:35 AM, Shad Laws <sh...@sh...> wrote:

> Hey everyone,
>
> As one of the steps before building up the tag album, I refactored how we
> setup and paginate collections (see View_Gallery::init_collection()).
>  Rather than do this independently for each of the five current cases, we
> have a little API to do it for us :-).
>
> One side effect of this is that the pagination module is no longer used
> anywhere.  Anybody mind if I remove it altogether, both from gallery3 and
> gallery3-vendor?
>
> Take care,
> Shad
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

Re: [Gallery-devel] RSS - should be UTF-8?

[Bharat M. <bh...@me...>]

I can't think of a reason why its not UTF-8.  Make it so!
On Jul 5, 2013 3:29 AM, "Shad Laws" <sh...@sh...> wrote:

> In a quick audit of content type encodings, I realized that RSS is the one
> place we do *not* specify UTF-8.  Should this be changed, or is there a
> specific reason why we're not doing this?
>
> Thanks,
> Shad
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

[Gallery-devel] RSS - should be UTF-8?

[Shad L. <sh...@sh...>]

In a quick audit of content type encodings, I realized that RSS is the one
place we do *not* specify UTF-8.  Should this be changed, or is there a
specific reason why we're not doing this?

Thanks,
Shad

[Gallery-devel] G3.1 - pagination module removal?

[Shad L. <sh...@sh...>]

Hey everyone,

As one of the steps before building up the tag album, I refactored how we
setup and paginate collections (see View_Gallery::init_collection()).
 Rather than do this independently for each of the five current cases, we
have a little API to do it for us :-).

One side effect of this is that the pagination module is no longer used
anywhere.  Anybody mind if I remove it altogether, both from gallery3 and
gallery3-vendor?

Take care,
Shad

Re: [Gallery-devel] Refactoring the search module...

[Bharat M. <bh...@me...>]

My day job makes it highly ironic that I haven't dug into how we do search
in Gallery *at all* over the years.  All that code is contributed!

In general, whatever you do here is going to be fine with me.  I'll
(eventually) read it over and try to make sense of it, but what you're
saying seems fine on the surface so go for it.



On Sat, Jun 29, 2013 at 11:47 PM, Shad Laws <sh...@sh...> wrote:

> Hey everyone,
>
> In the process of beefing-up G3.1's rest module, I added a search REST
> resource.  In the process, I started looking more closely at the
> search module, and had some thoughts.  Notably, I'd like to change how
> Search::add_query_terms() works.
>
> Summary: In 3.0.x, we use Search::add_query_terms() to add wildcarded
> terms to the search.  Example: a search of "foo bars" becomes "foo
> bars foo* bar*" after Search::add_query_terms().  I believe the
> philosophy here is this: "search for a more generic term, but put
> exact matches first."  In general, I like this philosophy, but I'm not
> entirely sure we've implemented it the best way.  So, I have a new
> proposal that I think is both simpler and more predictable.
>
> --
>
> First thought: search was written with a bunch of hand-coded MySQL
> queries, which seems less than ideal.  In particular, this recently
> led to a bug because we didn't count whitespace carefully enough.  To
> be fair, it's in part because it's kinda hard when all the segments
> are hand-coded.  Since Gallery sits atop Kohana's stack of OO tools to
> do the dirty work for us, I refactored it to use them.  Voilà - no
> more counting whitespace :-).
>
> This also gave me a chance to understand *why* we chose to build the
> "fulltext" query as we do.  Maybe it's just my naïveté with MySQL, but
> it took me quite awhile to understand why we used "IN BOOLEAN MODE"
> for one part of the query but not the other.  Finally, I got it:
> - "boolean" mode allows special operators (+, -, *,...), so it's best
> for *finding* which items match the search.  But, it doesn't give us a
> useful score.
> - "natural langauge" mode gives us a useful score, so it's best for
> *ordering* the found items.
> This approach makes good sense to me, and I took the liberty of adding
> comments to the Search::_build_query_base() so the next newbie doesn't
> have to pour through Oracle docs like I did to figure this out :-).
>
> So, onto Search::add_query_terms().  Here's how 3.0.x does it:
> - user search box - foo bars
> - natural language - foo bars foo* bar*
> - boolean mode - foo bars foo* bar*
>
> Notes:
> - it makes no sense to send wildcards to a natural language query as
> they're ignored.  The result is a query of "foo bars foo bar", which
> oddly doubles foo.
> - it makes no sense to send "foo foo*" to a boolean query as they're the
> same.
>
> Another example for 3.0.x, which illustrates how plurals are handled:
> - user search box - entry alumnus
> - natural language - entry alumnus entry* alumnu*
> - boolean mode - entry alumnus entry* alumnu*
>
> A more nuanced example for 3.0.x, which illustrates how special
> operators aren't considered (note: Search::add_query_terms() imposes a
> 5 term limit)
> - user search box - +(required terms) foo bars
> - natural language - +(required terms) foo bars required*
> - boolean mode - +(required terms) foo bars required*
>
> Another example for 3.0.x, which illustrates how quotes make adding
> extra terms a pain:
> - user search box - "exact match only"
> - natural language - "exact match only" match* only"*
> - boolean mode - "exact match only" match* only"*
>
> --
>
> Here's my proposal:
> - natural language - exact same as user search box.  MySQL will
> automatically ignore special operators.
> - boolean mode - add wildcards to existing terms, add no *new* terms.
> Also, use Inflector::singular() and Inflector::plural() to figure out
> wildcard placement.
>
> Example:
> - user search box - foo bars entry alumnus +required "exact phrase"
> - natural language - foo bars entry alumnus +required "exact phrase"
> [MySQL sees "foo bars entry alumnus required exact phrase"]
> - boolean mode - foo* bar* entr* alumn* +required* "exact phrase"
>
> The result keeps the same philosophy: search for a more generic term
> (boolean mode), but put exact matches first (natural language mode).
> Notes:
> - Simpler logic removes the need to figure out how to extend/limit
> extra terms, be smart with parentheses and quotes while extending,
> etc.
> - Use of Inflector class lets us be more clever with irregular plurals.
> - This still isn't i18n savvy, but I suspect that trying to be
> i18n-savvy comprehensively is a deep rabbit hole.
> - Maybe to at least be clear about our lack of i18n, we should add an
> admin option for wildcarding modes.  (Prefix mode: none, add wildcard;
> suffix mode: none, add wildcard, add smart wildcard (English only)).
> - If we go to the trouble of adding an admin screen, maybe it makes
> sense to fold in my short_search_fix module (enables search terms of
> <4 characters on shared hosting installations)
>
> Thoughts?
>
> Take care,
> Shad
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

Re: [Gallery-devel] Module order for hooks (event, theme, etc.)

[Bharat M. <bh...@me...>]

> This gives us a consistent priority/hierarchy setup while maintaining
> the same event ordering as before.  In other words, it makes
> nit-pickers like me happy while affecting approximately 0 actual users
> :-)
>
>
Thanks for  going all the way down this rabbit hole.  I definitely did not
think this through carefully enough in the 3.0.x - I like the fact that
we're going to have consistency between events and routes going forward.

[Gallery-devel] Refactoring the search module...

[Shad L. <sh...@sh...>]

Hey everyone,

In the process of beefing-up G3.1's rest module, I added a search REST
resource.  In the process, I started looking more closely at the
search module, and had some thoughts.  Notably, I'd like to change how
Search::add_query_terms() works.

Summary: In 3.0.x, we use Search::add_query_terms() to add wildcarded
terms to the search.  Example: a search of "foo bars" becomes "foo
bars foo* bar*" after Search::add_query_terms().  I believe the
philosophy here is this: "search for a more generic term, but put
exact matches first."  In general, I like this philosophy, but I'm not
entirely sure we've implemented it the best way.  So, I have a new
proposal that I think is both simpler and more predictable.

--

First thought: search was written with a bunch of hand-coded MySQL
queries, which seems less than ideal.  In particular, this recently
led to a bug because we didn't count whitespace carefully enough.  To
be fair, it's in part because it's kinda hard when all the segments
are hand-coded.  Since Gallery sits atop Kohana's stack of OO tools to
do the dirty work for us, I refactored it to use them.  Voilà - no
more counting whitespace :-).

This also gave me a chance to understand *why* we chose to build the
"fulltext" query as we do.  Maybe it's just my naïveté with MySQL, but
it took me quite awhile to understand why we used "IN BOOLEAN MODE"
for one part of the query but not the other.  Finally, I got it:
- "boolean" mode allows special operators (+, -, *,...), so it's best
for *finding* which items match the search.  But, it doesn't give us a
useful score.
- "natural langauge" mode gives us a useful score, so it's best for
*ordering* the found items.
This approach makes good sense to me, and I took the liberty of adding
comments to the Search::_build_query_base() so the next newbie doesn't
have to pour through Oracle docs like I did to figure this out :-).

So, onto Search::add_query_terms().  Here's how 3.0.x does it:
- user search box - foo bars
- natural language - foo bars foo* bar*
- boolean mode - foo bars foo* bar*

Notes:
- it makes no sense to send wildcards to a natural language query as
they're ignored.  The result is a query of "foo bars foo bar", which
oddly doubles foo.
- it makes no sense to send "foo foo*" to a boolean query as they're the same.

Another example for 3.0.x, which illustrates how plurals are handled:
- user search box - entry alumnus
- natural language - entry alumnus entry* alumnu*
- boolean mode - entry alumnus entry* alumnu*

A more nuanced example for 3.0.x, which illustrates how special
operators aren't considered (note: Search::add_query_terms() imposes a
5 term limit)
- user search box - +(required terms) foo bars
- natural language - +(required terms) foo bars required*
- boolean mode - +(required terms) foo bars required*

Another example for 3.0.x, which illustrates how quotes make adding
extra terms a pain:
- user search box - "exact match only"
- natural language - "exact match only" match* only"*
- boolean mode - "exact match only" match* only"*

--

Here's my proposal:
- natural language - exact same as user search box.  MySQL will
automatically ignore special operators.
- boolean mode - add wildcards to existing terms, add no *new* terms.
Also, use Inflector::singular() and Inflector::plural() to figure out
wildcard placement.

Example:
- user search box - foo bars entry alumnus +required "exact phrase"
- natural language - foo bars entry alumnus +required "exact phrase"
[MySQL sees "foo bars entry alumnus required exact phrase"]
- boolean mode - foo* bar* entr* alumn* +required* "exact phrase"

The result keeps the same philosophy: search for a more generic term
(boolean mode), but put exact matches first (natural language mode).
Notes:
- Simpler logic removes the need to figure out how to extend/limit
extra terms, be smart with parentheses and quotes while extending,
etc.
- Use of Inflector class lets us be more clever with irregular plurals.
- This still isn't i18n savvy, but I suspect that trying to be
i18n-savvy comprehensively is a deep rabbit hole.
- Maybe to at least be clear about our lack of i18n, we should add an
admin option for wildcarding modes.  (Prefix mode: none, add wildcard;
suffix mode: none, add wildcard, add smart wildcard (English only)).
- If we go to the trouble of adding an admin screen, maybe it makes
sense to fold in my short_search_fix module (enables search terms of
<4 characters on shared hosting installations)

Thoughts?

Take care,
Shad

Re: [Gallery-devel] Module order for hooks (event, theme, etc.)

[Shad L. <sh...@sh...>]

Hey everyone,

Okay, final followup: I implemented something slightly different from
what I said below.

Quick summary: module event order is the same as Gallery 3.0.x, so
this should affect approximately 0 people.

--

The modules are assigned a weight in the DB (for this example, "module
1" has weight 1, "module 2" has 2, etc.).  In Gallery 3.0.x, we sent
this module list to Kohana in a way that was inconsistent with the
order in which events are fired.

3.0.x class autoloading order (using list sent to Kohana):
- APPPATH
- active theme
- (unit test modules, if applicable)
- module 1
- module 2
- module 3
- gallery
- (3rd-party modules, e.g. forge)
- SYSPATH
Result: first modules get their extensions loaded first, so they have
priority - module 1 > module 3.

3.0.x module event order:
- gallery
- module 1
- module 2
- module 3
- active theme
Result: last modules get the final say in what happens, so they have
priority - module 3 > module 1.

In practice, it seems that no module cares about the class autoloading
order (so long as gallery is last), but several modules care about the
event order.  So, let's preserve that.

3.1.x class autoloading order:
- APPPATH
- active theme
- (unit test modules, if applicable)
- purifier
- module 3
- module 2
- module 1
- gallery
- (3rd-party modules, e.g. formo)
- SYSPATH
Result: first modules get their extensions loaded first, so they have
priority - module 3 > module 1.

3.0.x module event order:
- gallery
- module 1
- module 2
- module 3
- purifier
- active theme
Result: last modules get the final say in what happens, so they have
priority - module 3 > module 1.

This gives us a consistent priority/hierarchy setup while maintaining
the same event ordering as before.  In other words, it makes
nit-pickers like me happy while affecting approximately 0 actual users
:-)

Take care,
Shad


On 26 June 2013 11:15, Shad Laws <sh...@sh...> wrote:
> Quick followup... funny how writing things up can clarify things for you...
>
> At the end of the email, I proposed two options:
> - use *reverse* order by default, but give the option of running oppositely
> if asked.  This is the most flexible approach, but I'm unsure if we really
> need/want this flexibility.  Also, it implies that we'd run all of the
> gallery_ready events opposite of all other events, which is weird.
> - use *reverse* order always, and tell Kohana to look for routes in the
> opposite order.  This is actually pretty easy to do.
>
> ... and now realize that option 2 is definitely the better way to go.  In
> addition to what I said, there's another reason: running gallery_ready
> events in the opposite order of everything else (i.e. gallery module last)
> is a surefire way to break sso and user_homes.  This is because
> GalleryEvent::gallery_ready() is what loads the user in the first place, so
> it's gotta go first.
>
> Alright, ramble over.  Thanks for listening, or at least pretending to!
>
> Take care,
> Shad
>
>
>
>
> On 26 June 2013 10:59, Shad Laws <sh...@sh...> wrote:
>>
>> Hey everyone,
>>
>> Following on recent discussions of routing, init files, hooks, etc., I
>> jumped into unifying Gallery's hook-calling system.  It turns out that the
>> module order is a bit deeper of a rabbit hole than I originally thought...
>>
>> So, the idea of the cascading file system is to have multiple modules,
>> ordered by their "priority."  Let's say we have modules A, B, and C, where A
>> is highest and C is lowest priority.  Then, we'd setup our Kohana paths in
>> the following order:
>> - APPPATH
>> - active theme
>> - purifier
>> - module A
>> - module B
>> - module C
>> - gallery
>> - (formo, database, orm, etc.)
>> - SYSPATH
>>
>> Then, Kohana uses them like this:
>> - autoloading classes: uses *forward* order, and stops when it finds
>> something.  So, any high-priority module can override something lower on the
>> list.
>> - config files: uses *reverse* order, and goes through whole list.  So,
>> the high-priority modules get the last word - whatever variable the
>> low-priority ones set, the high-priority ones can change.
>>
>> This brings us to Gallery's hook system.  In Gallery 3.0.x, we used the
>> following order:
>> - gallery
>> - purifier
>> - module A
>> - module B
>> - module C
>> - active theme
>>
>> IMHO, this seems a bit ad hoc and not at all consistent - it shuffles the
>> stack priorities given elsewhere, simply reversing gallery and the active
>> theme and leaving the rest alone.  It should be either the same as the path
>> search order, or the exact opposite...
>>
>> ... but which one?  Some examples from the core code:
>> - menu: *reverse* order.  Gallery's menu system (e.g.
>> GalleryEvent::site_menu()) relies on the gallery module going first.  It
>> builds the basic menu, which other modules can modify.
>> - theme: *reverse* order.  Gallery's theme system builds HTML blocks in
>> the module order.  Here it also makes sense for the higher-priority modules
>> to go last, as they can add JS that modifies things above it.
>> - routes: *forward* order.  Kohana's routing/request system follows the
>> init file order, which prioritizes the routes defined first, not last.
>> Since we're doing away with init files, this doesn't help us.
>>
>> So, it looks like we have a couple options:
>> - use *reverse* order by default, but give the option of running
>> oppositely if asked.  This is the most flexible approach, but I'm unsure if
>> we really need/want this flexibility.  Also, it implies that we'd run all of
>> the gallery_ready events opposite of all other events, which is weird.
>> - use *reverse* order always, and tell Kohana to look for routes in the
>> opposite order.  This is actually pretty easy to do:
>>
>> class Gallery_Request extends Kohana_Request {
>>   public static function process(Request $request, $routes=null) {
>>     // Copy first line of Request::process(), but add array_reverse().
>>     $routes = (empty($routes)) ? array_reverse(Route::all()) :
>> array_reverse($routes);
>>     return parent::process($request, $routes);
>>   }
>> }
>>
>> My vote is for the second option - it keeps us 100% consistent with the
>> idea that high-priority things get the last word, and cleanly fixes the
>> *one* case where somebody feels otherwise.  That said, I could understand if
>> people prefer the opposite approach...
>>
>> One last note: this does have some minor implications for contrib modules.
>> In particular, things that required imposing a module order to ensure events
>> happen in sequence (rawphoto and autorotate before exif, tags before
>> tag_albums) will be temporarily broken until their order is reversed.  This
>> is easily fixed with another stanza in GalleryInstaller::upgrade(), ensuring
>> nothing gets broken.
>>
>> Thoughts?
>>
>> Take care,
>> Shad
>
>

Re: [Gallery-devel] [Gallery3] Unit test updates

[Shad L. <sh...@sh...>]

Hey Bharat,

(replying inline and snipping a bit...)

Here's my sketch of the end of index.php:
>>
>> // Initialize the framework.
>> require APPPATH . "bootstrap" . EXT;
>>
>> // Initialize the Gallery modules.
>> register_shutdown_function("Module::event", "shutdown");
>> Module::event("gallery_ready");
>>
>> // Build the initial request.
>> $request = Request::factory(true, array(), false);
>> Module::event("initial_request_ready");
>>
>> // Generate and send the response.
>> echo $request->execute()
>>   ->send_headers(true)
>>   ->body();
>>
>
> As I understand it, the routing decision happens in Request::execute() so
> at the initial_request_ready point in your sketch, routing hasn't happened.
>  So modules can't change the route, or at least not the way that we did in
> K2.
>

Different than K2, yes, but it actually works pretty well here.  There are
a few steps to routing:
- Run gallery_ready.  Here, we define the routes, which are how we parse
URIs into controller, action, etc.
- Run Request::factory(), return a Request object.  This builds the
request, gets the URI, but does *not* actually parse it and get controller,
action, etc.
- Run initial_request_ready.   Here, we can change the URI as our hearts
desire, before anyone else has gotten a chance to do anything with it.
- Run ->execute(), return a Response object.  This parses the URI, loads up
a controller, runs it, and returns its Response.

But, this did show me an odd wrinkle with module events: the module order
>> seems weird.
>> - active modules list: purifier, high_priority_module,
>> low_priority_module, gallery   (same as Kohana's list)
>> - current event order: gallery, purifier, high_priority_module,
>> low_priority_module   (put gallery first, leave rest as-is)
>> - proposed event order: gallery, low_priority_module,
>> high_priority_module, purifier   (reverse of active list, same as Kohana's
>> config file search)
>>
>> In other words, I think it should be changed to run the events in reverse
>> module order, thereby giving the high-priority modules the last word.  Is
>> there a reason we don't already do it this way?
>>
>> Among other advantages, if we can change this, then the routes get loaded
>> in the right order :-).
>>
>>
> What order did we do it in for K2?  I can't recall.  But I had a rationale
> for it then and we should try to preserve it (or at least understand it!).
>  Sorry for the short reply - I'm travelling and low on time.
>
>
It turns out this was a slightly deeper rabbit hole than I originally
thought... see other email chain.

No worries on being low on time!  Bon voyage :-)

Take care,
Shad

Re: [Gallery-devel] [Gallery3] Unit test updates

[Bharat M. <bh...@me...>]

On Mon, Jun 24, 2013 at 3:07 AM, Shad Laws <sh...@sh...> wrote:

> Hey Bharat,
>
> Hmm, I'm not sure I see routing and execution as one inseparable unit.  It
> seems to me that they decided to remove their event handler and instead
> make the cascading file system (which has far less exceptions to rules than
> before) and the config file system beefier to pick up the slack.  For
> example, extending the Controller class as we do is a nice way to split the
> two.  Alternatively, we can just generate the request and wait a tick
> before executing it.
>
> Here's my sketch of the end of index.php:
>
> // Initialize the framework.
> require APPPATH . "bootstrap" . EXT;
>
> // Initialize the Gallery modules.
> register_shutdown_function("Module::event", "shutdown");
> Module::event("gallery_ready");
>
> // Build the initial request.
> $request = Request::factory(true, array(), false);
> Module::event("initial_request_ready");
>
> // Generate and send the response.
> echo $request->execute()
>   ->send_headers(true)
>   ->body();
>

As I understand it, the routing decision happens in Request::execute() so
at the initial_request_ready point in your sketch, routing hasn't happened.
 So modules can't change the route, or at least not the way that we did in
K2.


> The functions Gallery::ready() and Gallery::shutdown() are removed, as
> they were just one-line wrappers around their respective module events.  I
> like this more direct approach.
>

Sounds good.


>
> But, this did show me an odd wrinkle with module events: the module order
> seems weird.
> - active modules list: purifier, high_priority_module,
> low_priority_module, gallery   (same as Kohana's list)
> - current event order: gallery, purifier, high_priority_module,
> low_priority_module   (put gallery first, leave rest as-is)
> - proposed event order: gallery, low_priority_module,
> high_priority_module, purifier   (reverse of active list, same as Kohana's
> config file search)
>
> In other words, I think it should be changed to run the events in reverse
> module order, thereby giving the high-priority modules the last word.  Is
> there a reason we don't already do it this way?
>
> Among other advantages, if we can change this, then the routes get loaded
> in the right order :-).
>
>
What order did we do it in for K2?  I can't recall.  But I had a rationale
for it then and we should try to preserve it (or at least understand it!).
 Sorry for the short reply - I'm travelling and low on time.

Re: [Gallery-devel] Module order for hooks (event, theme, etc.)

[Shad L. <sh...@sh...>]

Quick followup... funny how writing things up can clarify things for you...

At the end of the email, I proposed two options:
- use *reverse* order by default, but give the option of running oppositely
if asked.  This is the most flexible approach, but I'm unsure if we really
need/want this flexibility.  Also, it implies that we'd run all of the
gallery_ready events opposite of all other events, which is weird.
- use *reverse* order always, and tell Kohana to look for routes in the
opposite order.  This is actually pretty easy to do.

... and now realize that option 2 is definitely the better way to go.  In
addition to what I said, there's another reason: running gallery_ready
events in the opposite order of everything else (i.e. gallery module last)
is a surefire way to break sso and user_homes.  This is because
GalleryEvent::gallery_ready() is what loads the user in the first place, so
it's gotta go first.

Alright, ramble over.  Thanks for listening, or at least pretending to!

Take care,
Shad




On 26 June 2013 10:59, Shad Laws <sh...@sh...> wrote:

> Hey everyone,
>
> Following on recent discussions of routing, init files, hooks, etc., I
> jumped into unifying Gallery's hook-calling system.  It turns out that the
> module order is a bit deeper of a rabbit hole than I originally thought...
>
> So, the idea of the cascading file system is to have multiple modules,
> ordered by their "priority."  Let's say we have modules A, B, and C, where
> A is highest and C is lowest priority.  Then, we'd setup our Kohana paths
> in the following order:
> - APPPATH
> - active theme
> - purifier
> - module A
> - module B
> - module C
> - gallery
> - (formo, database, orm, etc.)
> - SYSPATH
>
> Then, Kohana uses them like this:
> - autoloading classes: uses *forward* order, and stops when it finds
> something.  So, any high-priority module can override something lower on
> the list.
> - config files: uses *reverse* order, and goes through whole list.  So,
> the high-priority modules get the last word - whatever variable the
> low-priority ones set, the high-priority ones can change.
>
> This brings us to Gallery's hook system.  In Gallery 3.0.x, we used the
> following order:
> - gallery
> - purifier
> - module A
> - module B
> - module C
> - active theme
>
> IMHO, this seems a bit ad hoc and not at all consistent - it shuffles the
> stack priorities given elsewhere, simply reversing gallery and the active
> theme and leaving the rest alone.  It should be either the same as the path
> search order, or the exact opposite...
>
> ... but which one?  Some examples from the core code:
> - menu: *reverse* order.  Gallery's menu system (e.g.
> GalleryEvent::site_menu()) relies on the gallery module going first.  It
> builds the basic menu, which other modules can modify.
> - theme: *reverse* order.  Gallery's theme system builds HTML blocks in
> the module order.  Here it also makes sense for the higher-priority modules
> to go last, as they can add JS that modifies things above it.
> - routes: *forward* order.  Kohana's routing/request system follows the
> init file order, which prioritizes the routes defined first, not last.
>  Since we're doing away with init files, this doesn't help us.
>
> So, it looks like we have a couple options:
> - use *reverse* order by default, but give the option of running
> oppositely if asked.  This is the most flexible approach, but I'm unsure if
> we really need/want this flexibility.  Also, it implies that we'd run all
> of the gallery_ready events opposite of all other events, which is weird.
> - use *reverse* order always, and tell Kohana to look for routes in the
> opposite order.  This is actually pretty easy to do:
>
> class Gallery_Request extends Kohana_Request {
>   public static function process(Request $request, $routes=null) {
>     // Copy first line of Request::process(), but add array_reverse().
>     $routes = (empty($routes)) ? array_reverse(Route::all()) :
> array_reverse($routes);
>     return parent::process($request, $routes);
>   }
> }
>
> My vote is for the second option - it keeps us 100% consistent with the
> idea that high-priority things get the last word, and cleanly fixes the
> *one* case where somebody feels otherwise.  That said, I could understand
> if people prefer the opposite approach...
>
> One last note: this does have some minor implications for contrib modules.
>  In particular, things that required imposing a module order to ensure
> events happen in sequence (rawphoto and autorotate before exif, tags before
> tag_albums) will be temporarily broken until their order is reversed.  This
> is easily fixed with another stanza in GalleryInstaller::upgrade(),
> ensuring nothing gets broken.
>
> Thoughts?
>
> Take care,
> Shad
>

[Gallery-devel] Module order for hooks (event, theme, etc.)

[Shad L. <sh...@sh...>]

Hey everyone,

Following on recent discussions of routing, init files, hooks, etc., I
jumped into unifying Gallery's hook-calling system.  It turns out that the
module order is a bit deeper of a rabbit hole than I originally thought...

So, the idea of the cascading file system is to have multiple modules,
ordered by their "priority."  Let's say we have modules A, B, and C, where
A is highest and C is lowest priority.  Then, we'd setup our Kohana paths
in the following order:
- APPPATH
- active theme
- purifier
- module A
- module B
- module C
- gallery
- (formo, database, orm, etc.)
- SYSPATH

Then, Kohana uses them like this:
- autoloading classes: uses *forward* order, and stops when it finds
something.  So, any high-priority module can override something lower on
the list.
- config files: uses *reverse* order, and goes through whole list.  So, the
high-priority modules get the last word - whatever variable the
low-priority ones set, the high-priority ones can change.

This brings us to Gallery's hook system.  In Gallery 3.0.x, we used the
following order:
- gallery
- purifier
- module A
- module B
- module C
- active theme

IMHO, this seems a bit ad hoc and not at all consistent - it shuffles the
stack priorities given elsewhere, simply reversing gallery and the active
theme and leaving the rest alone.  It should be either the same as the path
search order, or the exact opposite...

... but which one?  Some examples from the core code:
- menu: *reverse* order.  Gallery's menu system (e.g.
GalleryEvent::site_menu()) relies on the gallery module going first.  It
builds the basic menu, which other modules can modify.
- theme: *reverse* order.  Gallery's theme system builds HTML blocks in the
module order.  Here it also makes sense for the higher-priority modules to
go last, as they can add JS that modifies things above it.
- routes: *forward* order.  Kohana's routing/request system follows the
init file order, which prioritizes the routes defined first, not last.
 Since we're doing away with init files, this doesn't help us.

So, it looks like we have a couple options:
- use *reverse* order by default, but give the option of running oppositely
if asked.  This is the most flexible approach, but I'm unsure if we really
need/want this flexibility.  Also, it implies that we'd run all of the
gallery_ready events opposite of all other events, which is weird.
- use *reverse* order always, and tell Kohana to look for routes in the
opposite order.  This is actually pretty easy to do:

class Gallery_Request extends Kohana_Request {
  public static function process(Request $request, $routes=null) {
    // Copy first line of Request::process(), but add array_reverse().
    $routes = (empty($routes)) ? array_reverse(Route::all()) :
array_reverse($routes);
    return parent::process($request, $routes);
  }
}

My vote is for the second option - it keeps us 100% consistent with the
idea that high-priority things get the last word, and cleanly fixes the
*one* case where somebody feels otherwise.  That said, I could understand
if people prefer the opposite approach...

One last note: this does have some minor implications for contrib modules.
 In particular, things that required imposing a module order to ensure
events happen in sequence (rawphoto and autorotate before exif, tags before
tag_albums) will be temporarily broken until their order is reversed.  This
is easily fixed with another stanza in GalleryInstaller::upgrade(),
ensuring nothing gets broken.

Thoughts?

Take care,
Shad

Re: [Gallery-devel] [Gallery3] Unit test updates

[Shad L. <sh...@sh...>]

Hey Bharat,

Hmm, I'm not sure I see routing and execution as one inseparable unit.  It
seems to me that they decided to remove their event handler and instead
make the cascading file system (which has far less exceptions to rules than
before) and the config file system beefier to pick up the slack.  For
example, extending the Controller class as we do is a nice way to split the
two.  Alternatively, we can just generate the request and wait a tick
before executing it.

Here's my sketch of the end of index.php:

// Initialize the framework.
require APPPATH . "bootstrap" . EXT;

// Initialize the Gallery modules.
register_shutdown_function("Module::event", "shutdown");
Module::event("gallery_ready");

// Build the initial request.
$request = Request::factory(true, array(), false);
Module::event("initial_request_ready");

// Generate and send the response.
echo $request->execute()
  ->send_headers(true)
  ->body();

The functions Gallery::ready() and Gallery::shutdown() are removed, as they
were just one-line wrappers around their respective module events.  I like
this more direct approach.

But, this did show me an odd wrinkle with module events: the module order
seems weird.
- active modules list: purifier, high_priority_module, low_priority_module,
gallery   (same as Kohana's list)
- current event order: gallery, purifier, high_priority_module,
low_priority_module   (put gallery first, leave rest as-is)
- proposed event order: gallery, low_priority_module, high_priority_module,
purifier   (reverse of active list, same as Kohana's config file search)

In other words, I think it should be changed to run the events in reverse
module order, thereby giving the high-priority modules the last word.  Is
there a reason we don't already do it this way?

Among other advantages, if we can change this, then the routes get loaded
in the right order :-).

Take care,
Shad


On 24 June 2013 00:33, Bharat Mediratta <bh...@me...> wrote:

>
>
>
> On Sun, Jun 23, 2013 at 8:33 AM, Shad Laws <sh...@sh...> wrote:
>
>> Hey Bharat,
>>
>> Overall, makes sense to me.  A couple points:
>> - My guess is that K3 intentionally dropped the postrouting events with
>> the MVC-->HMVC change since routing occurs with every new request <shrug>.
>> - I'm not sure I like "gallery_request_ready" as I feel like it should
>> run with every request (which it doesn't - in K3-speak, it fires only in
>> the initial request and not on sub-requests).  Perhaps
>> "initial_request_ready" instead?
>>
>
> That makes total sense.  I forgot about the fact that you can go through
> that process multiple times.  It's irritating to me that they made the
> routing and execution a single inseparable unit.
>
>
>> - The shutdown function currently uses PHP's register_shutdown_function()
>> in the bootstrap  (
>> https://github.com/gallery/gallery3/blob/kohana_3/application/bootstrap.php#L245).
>>  I'm in no way committed to its placement... if you'd like it elsewhere,
>> that works for me, too :-).
>>
>
> Ok that makes sense too - that way it gets called even if there's an
> exception or an error.  We should keep it that way.
>
>
>> - Your partition of the tasks by event makes sense to me.  Is there any
>> reason the bot detection part is in Gallery::ready() instead of
>> Hook_GalleryEvent::gallery_ready()?
>>
>
> No, just arbitrary.
>
>
>> - Agreed - user_homes and sso should still work just fine with the new
>> events.
>>
>> Oh, and re: rambly stream of consciousness, I'm probably not in a great
>> position to critique emails like that as of late... :-)
>>
>> Thoughts?
>>
>
> All sounds good to me!
>
>
>>
>> Take care,
>> Shad
>>
>>
>> On 21 June 2013 19:36, Bharat Mediratta <bh...@me...> wrote:
>>
>>> (sorry for the rambly stream of consciousness here, sorry)
>>>
>>> Ok, backing up to a high level - the issue is that we need to reboot our
>>> routes every time there's a module change, right?  So by the time we get to
>>> Controller::execute() we need to have initialized our routes already, which
>>> is why we do it in init.php.  And we need our own Route::init() function
>>> that goes off and gets routes from all the modules.
>>>
>>> Makes sense to have two events.  But I think it's a little weird to say
>>> "before_initial_request" and "after_initial_request" because the after one
>>> implies to me that the request is done.  In K2 it was "prerouting" and
>>> "postrouting" but those were Kohana events, not Gallery events.
>>>
>>> There are two ways to think about our events.  One is to instruct
>>> modules to take an action, like "please inject your routes now".  The other
>>> is to let modules know that we're at a milestone, like "Hey the Gallery is
>>> ready".  Kohana takes the milestone approach, but Gallery takes the action
>>> approach (with the exception of "gallery_ready" and "gallery_shutdown").
>>>
>>> It's irritating that K3 doesn't have a "postrouting" style hook for us.
>>>
>>> One quick note is that I think we should put these events in index.php
>>> since they're about the lifecycle of the app, so it'd look like this:
>>>
>>> // Initialize the framework.
>>> require APPPATH . "bootstrap" . EXT;
>>>
>>> *Gallery::ready();*
>>>
>>> // Go!
>>> echo Request::factory(true, array(), false)
>>>   ->execute()
>>>   ->send_headers(true)->body();
>>>
>>> *Gallery::shutdown();*
>>>
>>> Then in Gallery_Controller::execute() we can have a new event which is "
>>> *gallery_request_ready*" which means "the request is ready but hasn't
>>> been executed yet".  That should allow us to load the theme and set the
>>> request locale after we have a request.  So in Gallery_Hook_GalleryEvent:
>>>
>>> gallery_ready()
>>> - set date.timezone
>>> - Identity::load_user()
>>>
>>> gallery_request_ready():
>>> - bot detection
>>> - Theme::load_themes()
>>> - Locales::set_request_locale()
>>>
>>>
>>> I think this is generally where you got.. does that sound right to you?
>>>
>>> Notes:
>>> -  I don't see where Gallery::shutdown is called in the new code.  Did
>>> that get dropped?
>>> - the 3.0 user_homes module uses gallery_ready to redirect the user to a
>>> new location before the request occurs - I think we can still do that in
>>> the 3.1 gallery_ready
>>> - the 3.0 sso module uses gallery_ready to change the active user - I
>>> think the 3.1 gallery_ready works for that as well
>>>
>>>
>>>
>>> On Thu, Jun 20, 2013 at 11:06 PM, Shad Laws <sh...@sh...> wrote:
>>>
>>>> I tried playing with this, and now remember why we put it in
>>>> Controller::execute() - if we put it before the initial request generation,
>>>> we (unsurprisingly) don't have access to a populated Request object.  In
>>>> particular, this screws up Theme::load_themes(), which uses Request to
>>>> figure out if we're in admin mode or have an override.  It also screws up
>>>> our check for a robot user_agent - while it doesn't bomb the code,
>>>> Request::user_agent() checks against a still-unset value.
>>>>
>>>> A few options:
>>>> - hack Theme::load_themes() and the robot check to no longer need
>>>> Request.  While technically possible, this sounds messy... I don't think
>>>> it's a good approach.
>>>> - move a couple things out of the "ready" event, and leave them in
>>>> Controller::execute().  This gets the job done without major hacks, but the
>>>> fact that we need to do this in the first place hints that a better
>>>> approach would be to...
>>>> - have two events, one right before the initial Request and one right
>>>> after.  This is my current favorite approach.
>>>>
>>>> Next question: if we do the two-event option, what should they be
>>>> called?  Some possibilities:
>>>> - Before request: init (exact Kohana analog), routes (most common
>>>> application), bootstrap, before_initial_request
>>>> - After request: gallery_ready (current name), ready (shorter name),
>>>> after_initial_request
>>>>
>>>> Thoughts?
>>>> Shad
>>>>
>>>> On 21 June 2013 01:12, Bharat Mediratta <bh...@me...> wrote:
>>>>
>>>>>
>>>>> I think that's reasonable.  I've never been 100% happy with putting
>>>>> the "ready" event in Controller::execute.
>>>>>
>>>>>
>>>>> On Thu, Jun 20, 2013 at 3:44 PM, Shad Laws <sh...@sh...> wrote:
>>>>>
>>>>>> I like the idea of reducing the init.php's down to zero and putting
>>>>>> it in an event, and agree that trying to keep track of this isn't a good
>>>>>> idea.  In fact, we could probably just move the execution of the
>>>>>> already-existing "ready" event from Controller::execute() to either
>>>>>> bootstrap.php or index.php (just before the initial request generation).  I
>>>>>> wonder - should it be renamed "init" to make its analog more obvious?
>>>>>>
>>>>>> Then, we just add a Route override that clears out the Route list,
>>>>>> and use it in Module to activate/deactivate things as well as in the unit
>>>>>> test.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Take care,
>>>>>> Shad
>>>>>>
>>>>>> On 21 June 2013 00:12, Bharat Mediratta <bh...@me...> wrote:
>>>>>>
>>>>>>>
>>>>>>> I've been wondering about that as well, but I wasn't thinking about
>>>>>>> it from the unit test perspective.  I was thinking more along the lines of
>>>>>>> activating and deactivating modules during a request's lifetime.  Eg, if we
>>>>>>> deactivate and reactivate a module several times, what is a developer
>>>>>>> supposed to do about their code in init.php?  Should devs guard against
>>>>>>> their code being called multiple times?  It feels messy to me.
>>>>>>>
>>>>>>> I think a better approach would be to minimize what goes into
>>>>>>> init.php, preferably down to zero.  We can leave the facility around, but
>>>>>>> since we're only using it for routes I think we could easily have an event
>>>>>>> hook which sets routes, then we can call that from Module whenever we add a
>>>>>>> module.
>>>>>>>
>>>>>>> If we want to be smart about removing routes when a module is
>>>>>>> deactivated (not essential for us to do right now, IMO) we could always
>>>>>>> track which routes were added when we call the hook and remove them when
>>>>>>> the module goes away, similar to how we do Graphics::deactivate_rules
>>>>>>> and BlockManager::deactivate_blocks...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 20, 2013 at 10:52 AM, Shad Laws <sh...@sh...>wrote:
>>>>>>>
>>>>>>>> Hey Bharat,
>>>>>>>>
>>>>>>>> It looks like, except for the REST-related unit tests I'm still
>>>>>>>> wrapping up, the only tests left are controller auth and XSS - woohoo!
>>>>>>>>
>>>>>>>> I did, however, hit a minor snag.  I got everything running well
>>>>>>>> and passing, hit a reset button, and then everything broke with the REST
>>>>>>>> tests - crap!  After a bit of digging, I found the problem: the REST tests
>>>>>>>> won't pass on a fresh installation.  They only pass if you activate the
>>>>>>>> rest module, *then* run unit tests.
>>>>>>>>
>>>>>>>> The issue is the rest module's init.php file.  Like the other
>>>>>>>> init.php files (e.g. in tag), it's designed to run *before* the bootstrap
>>>>>>>> routes are defined.  That way, they get precedence.  However, if you roll a
>>>>>>>> fresh install (which has rest disabled) straight into a unit test, it bombs
>>>>>>>> - the bootstrap runs first, then rest's init.php later... and it doesn't
>>>>>>>> work :-/
>>>>>>>>
>>>>>>>> One thought I have is to override the Route class so we can clear
>>>>>>>> them and restart from scratch, then make the unit tests re-load them all...
>>>>>>>> but that sounds kinda hacky and flaky (e.g. what happens if an init.php
>>>>>>>> does something besides load routes?).  Any better thoughts?
>>>>>>>>
>>>>>>>> Take care,
>>>>>>>> Shad
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Gallery-devel] Metadata request (Bharat Mediratta)

[Wayne P. <sup...@fl...>]

I'm in favor of Open Graph, and it does not hurt pageload times, just wish
more apps took advantage of it.

Re: [Gallery-devel] [Gallery3] Unit test updates

[Bharat M. <bh...@me...>]

On Sun, Jun 23, 2013 at 8:33 AM, Shad Laws <sh...@sh...> wrote:

> Hey Bharat,
>
> Overall, makes sense to me.  A couple points:
> - My guess is that K3 intentionally dropped the postrouting events with
> the MVC-->HMVC change since routing occurs with every new request <shrug>.
> - I'm not sure I like "gallery_request_ready" as I feel like it should run
> with every request (which it doesn't - in K3-speak, it fires only in the
> initial request and not on sub-requests).  Perhaps "initial_request_ready"
> instead?
>

That makes total sense.  I forgot about the fact that you can go through
that process multiple times.  It's irritating to me that they made the
routing and execution a single inseparable unit.


> - The shutdown function currently uses PHP's register_shutdown_function()
> in the bootstrap  (
> https://github.com/gallery/gallery3/blob/kohana_3/application/bootstrap.php#L245).
>  I'm in no way committed to its placement... if you'd like it elsewhere,
> that works for me, too :-).
>

Ok that makes sense too - that way it gets called even if there's an
exception or an error.  We should keep it that way.


> - Your partition of the tasks by event makes sense to me.  Is there any
> reason the bot detection part is in Gallery::ready() instead of
> Hook_GalleryEvent::gallery_ready()?
>

No, just arbitrary.


> - Agreed - user_homes and sso should still work just fine with the new
> events.
>
> Oh, and re: rambly stream of consciousness, I'm probably not in a great
> position to critique emails like that as of late... :-)
>
> Thoughts?
>

All sounds good to me!


>
> Take care,
> Shad
>
>
> On 21 June 2013 19:36, Bharat Mediratta <bh...@me...> wrote:
>
>> (sorry for the rambly stream of consciousness here, sorry)
>>
>> Ok, backing up to a high level - the issue is that we need to reboot our
>> routes every time there's a module change, right?  So by the time we get to
>> Controller::execute() we need to have initialized our routes already, which
>> is why we do it in init.php.  And we need our own Route::init() function
>> that goes off and gets routes from all the modules.
>>
>> Makes sense to have two events.  But I think it's a little weird to say
>> "before_initial_request" and "after_initial_request" because the after one
>> implies to me that the request is done.  In K2 it was "prerouting" and
>> "postrouting" but those were Kohana events, not Gallery events.
>>
>> There are two ways to think about our events.  One is to instruct modules
>> to take an action, like "please inject your routes now".  The other is to
>> let modules know that we're at a milestone, like "Hey the Gallery is
>> ready".  Kohana takes the milestone approach, but Gallery takes the action
>> approach (with the exception of "gallery_ready" and "gallery_shutdown").
>>
>> It's irritating that K3 doesn't have a "postrouting" style hook for us.
>>
>> One quick note is that I think we should put these events in index.php
>> since they're about the lifecycle of the app, so it'd look like this:
>>
>> // Initialize the framework.
>> require APPPATH . "bootstrap" . EXT;
>>
>> *Gallery::ready();*
>>
>> // Go!
>> echo Request::factory(true, array(), false)
>>   ->execute()
>>   ->send_headers(true)->body();
>>
>> *Gallery::shutdown();*
>>
>> Then in Gallery_Controller::execute() we can have a new event which is "*
>> gallery_request_ready*" which means "the request is ready but hasn't
>> been executed yet".  That should allow us to load the theme and set the
>> request locale after we have a request.  So in Gallery_Hook_GalleryEvent:
>>
>> gallery_ready()
>> - set date.timezone
>> - Identity::load_user()
>>
>> gallery_request_ready():
>> - bot detection
>> - Theme::load_themes()
>> - Locales::set_request_locale()
>>
>>
>> I think this is generally where you got.. does that sound right to you?
>>
>> Notes:
>> -  I don't see where Gallery::shutdown is called in the new code.  Did
>> that get dropped?
>> - the 3.0 user_homes module uses gallery_ready to redirect the user to a
>> new location before the request occurs - I think we can still do that in
>> the 3.1 gallery_ready
>> - the 3.0 sso module uses gallery_ready to change the active user - I
>> think the 3.1 gallery_ready works for that as well
>>
>>
>>
>> On Thu, Jun 20, 2013 at 11:06 PM, Shad Laws <sh...@sh...> wrote:
>>
>>> I tried playing with this, and now remember why we put it in
>>> Controller::execute() - if we put it before the initial request generation,
>>> we (unsurprisingly) don't have access to a populated Request object.  In
>>> particular, this screws up Theme::load_themes(), which uses Request to
>>> figure out if we're in admin mode or have an override.  It also screws up
>>> our check for a robot user_agent - while it doesn't bomb the code,
>>> Request::user_agent() checks against a still-unset value.
>>>
>>> A few options:
>>> - hack Theme::load_themes() and the robot check to no longer need
>>> Request.  While technically possible, this sounds messy... I don't think
>>> it's a good approach.
>>> - move a couple things out of the "ready" event, and leave them in
>>> Controller::execute().  This gets the job done without major hacks, but the
>>> fact that we need to do this in the first place hints that a better
>>> approach would be to...
>>> - have two events, one right before the initial Request and one right
>>> after.  This is my current favorite approach.
>>>
>>> Next question: if we do the two-event option, what should they be
>>> called?  Some possibilities:
>>> - Before request: init (exact Kohana analog), routes (most common
>>> application), bootstrap, before_initial_request
>>> - After request: gallery_ready (current name), ready (shorter name),
>>> after_initial_request
>>>
>>> Thoughts?
>>> Shad
>>>
>>> On 21 June 2013 01:12, Bharat Mediratta <bh...@me...> wrote:
>>>
>>>>
>>>> I think that's reasonable.  I've never been 100% happy with putting the
>>>> "ready" event in Controller::execute.
>>>>
>>>>
>>>> On Thu, Jun 20, 2013 at 3:44 PM, Shad Laws <sh...@sh...> wrote:
>>>>
>>>>> I like the idea of reducing the init.php's down to zero and putting it
>>>>> in an event, and agree that trying to keep track of this isn't a good idea.
>>>>>  In fact, we could probably just move the execution of the already-existing
>>>>> "ready" event from Controller::execute() to either bootstrap.php or
>>>>> index.php (just before the initial request generation).  I wonder - should
>>>>> it be renamed "init" to make its analog more obvious?
>>>>>
>>>>> Then, we just add a Route override that clears out the Route list, and
>>>>> use it in Module to activate/deactivate things as well as in the unit test.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Take care,
>>>>> Shad
>>>>>
>>>>> On 21 June 2013 00:12, Bharat Mediratta <bh...@me...> wrote:
>>>>>
>>>>>>
>>>>>> I've been wondering about that as well, but I wasn't thinking about
>>>>>> it from the unit test perspective.  I was thinking more along the lines of
>>>>>> activating and deactivating modules during a request's lifetime.  Eg, if we
>>>>>> deactivate and reactivate a module several times, what is a developer
>>>>>> supposed to do about their code in init.php?  Should devs guard against
>>>>>> their code being called multiple times?  It feels messy to me.
>>>>>>
>>>>>> I think a better approach would be to minimize what goes into
>>>>>> init.php, preferably down to zero.  We can leave the facility around, but
>>>>>> since we're only using it for routes I think we could easily have an event
>>>>>> hook which sets routes, then we can call that from Module whenever we add a
>>>>>> module.
>>>>>>
>>>>>> If we want to be smart about removing routes when a module is
>>>>>> deactivated (not essential for us to do right now, IMO) we could always
>>>>>> track which routes were added when we call the hook and remove them when
>>>>>> the module goes away, similar to how we do Graphics::deactivate_rules
>>>>>> and BlockManager::deactivate_blocks...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 20, 2013 at 10:52 AM, Shad Laws <sh...@sh...>wrote:
>>>>>>
>>>>>>> Hey Bharat,
>>>>>>>
>>>>>>> It looks like, except for the REST-related unit tests I'm still
>>>>>>> wrapping up, the only tests left are controller auth and XSS - woohoo!
>>>>>>>
>>>>>>> I did, however, hit a minor snag.  I got everything running well and
>>>>>>> passing, hit a reset button, and then everything broke with the REST tests
>>>>>>> - crap!  After a bit of digging, I found the problem: the REST tests won't
>>>>>>> pass on a fresh installation.  They only pass if you activate the rest
>>>>>>> module, *then* run unit tests.
>>>>>>>
>>>>>>> The issue is the rest module's init.php file.  Like the other
>>>>>>> init.php files (e.g. in tag), it's designed to run *before* the bootstrap
>>>>>>> routes are defined.  That way, they get precedence.  However, if you roll a
>>>>>>> fresh install (which has rest disabled) straight into a unit test, it bombs
>>>>>>> - the bootstrap runs first, then rest's init.php later... and it doesn't
>>>>>>> work :-/
>>>>>>>
>>>>>>> One thought I have is to override the Route class so we can clear
>>>>>>> them and restart from scratch, then make the unit tests re-load them all...
>>>>>>> but that sounds kinda hacky and flaky (e.g. what happens if an init.php
>>>>>>> does something besides load routes?).  Any better thoughts?
>>>>>>>
>>>>>>> Take care,
>>>>>>> Shad
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Gallery-devel] Metadata request

[Shad L. <sh...@sh...>]

One thought: if we go down this road, we probably should take a peek at the
other OpenGraph metadata, too:
http://ogp.me/

Take care,
Shad

On 23 June 2013 18:43, Bharat Mediratta <bh...@me...> wrote:

>
> I got this request in a private message, what do you guys think?
>
> May I please suggest future releases have the following meta data included
> in Gallery by default. Right now each individual theme has a page.html.php
> file where the metadata is contained. Unfortunately the data consists of
> only<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
> With the rise in use of FaceBook as a base to share pictures and videos
> this meta data is deficient in tags that allow users to post links to their
> videos and have a thumb and description show up with the normal text link.
> By inserting
>
>
> <meta property="og:image" content="<?= $theme->item->thumb_url(true)?>"/ >
>   <meta property="og:title" content="<?=  $theme->item()->title ?>" />
>   <meta property="og:description"content="<?= $theme->item()->description ?> " />
>   <meta property="og:url" content="<?= $theme->item->abs_url() ?>" />
>
> into the file Gallery is 100% compatible with the FaceBook debugger. This
> allows not only the text and description link but it inserts the thumbnail
> as well.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

[Gallery-devel] Metadata request

[Bharat M. <bh...@me...>]

I got this request in a private message, what do you guys think?

May I please suggest future releases have the following meta data included
in Gallery by default. Right now each individual theme has a page.html.php
file where the metadata is contained. Unfortunately the data consists of
only<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
With the rise in use of FaceBook as a base to share pictures and videos
this meta data is deficient in tags that allow users to post links to their
videos and have a thumb and description show up with the normal text link.
By inserting


<meta property="og:image" content="<?= $theme->item->thumb_url(true)?>"/ >
  <meta property="og:title" content="<?=  $theme->item()->title ?>" />
  <meta property="og:description"content="<?=
$theme->item()->description ?> " />
  <meta property="og:url" content="<?= $theme->item->abs_url() ?>" />

into the file Gallery is 100% compatible with the FaceBook debugger. This
allows not only the text and description link but it inserts the thumbnail
as well.

Re: [Gallery-devel] [Gallery3] Unit test updates

[Shad L. <sh...@sh...>]

Hey Bharat,

Overall, makes sense to me.  A couple points:
- My guess is that K3 intentionally dropped the postrouting events with the
MVC-->HMVC change since routing occurs with every new request <shrug>.
- I'm not sure I like "gallery_request_ready" as I feel like it should run
with every request (which it doesn't - in K3-speak, it fires only in the
initial request and not on sub-requests).  Perhaps "initial_request_ready"
instead?
- The shutdown function currently uses PHP's register_shutdown_function()
in the bootstrap  (
https://github.com/gallery/gallery3/blob/kohana_3/application/bootstrap.php#L245).
 I'm in no way committed to its placement... if you'd like it elsewhere,
that works for me, too :-).
- Your partition of the tasks by event makes sense to me.  Is there any
reason the bot detection part is in Gallery::ready() instead of
Hook_GalleryEvent::gallery_ready()?
- Agreed - user_homes and sso should still work just fine with the new
events.

Oh, and re: rambly stream of consciousness, I'm probably not in a great
position to critique emails like that as of late... :-)

Thoughts?

Take care,
Shad

On 21 June 2013 19:36, Bharat Mediratta <bh...@me...> wrote:

> (sorry for the rambly stream of consciousness here, sorry)
>
> Ok, backing up to a high level - the issue is that we need to reboot our
> routes every time there's a module change, right?  So by the time we get to
> Controller::execute() we need to have initialized our routes already, which
> is why we do it in init.php.  And we need our own Route::init() function
> that goes off and gets routes from all the modules.
>
> Makes sense to have two events.  But I think it's a little weird to say
> "before_initial_request" and "after_initial_request" because the after one
> implies to me that the request is done.  In K2 it was "prerouting" and
> "postrouting" but those were Kohana events, not Gallery events.
>
> There are two ways to think about our events.  One is to instruct modules
> to take an action, like "please inject your routes now".  The other is to
> let modules know that we're at a milestone, like "Hey the Gallery is
> ready".  Kohana takes the milestone approach, but Gallery takes the action
> approach (with the exception of "gallery_ready" and "gallery_shutdown").
>
> It's irritating that K3 doesn't have a "postrouting" style hook for us.
>
> One quick note is that I think we should put these events in index.php
> since they're about the lifecycle of the app, so it'd look like this:
>
> // Initialize the framework.
> require APPPATH . "bootstrap" . EXT;
>
> *Gallery::ready();*
>
> // Go!
> echo Request::factory(true, array(), false)
>   ->execute()
>   ->send_headers(true)->body();
>
> *Gallery::shutdown();*
>
> Then in Gallery_Controller::execute() we can have a new event which is "*
> gallery_request_ready*" which means "the request is ready but hasn't been
> executed yet".  That should allow us to load the theme and set the request
> locale after we have a request.  So in Gallery_Hook_GalleryEvent:
>
> gallery_ready()
> - set date.timezone
> - Identity::load_user()
>
> gallery_request_ready():
> - bot detection
> - Theme::load_themes()
> - Locales::set_request_locale()
>
>
> I think this is generally where you got.. does that sound right to you?
>
> Notes:
> -  I don't see where Gallery::shutdown is called in the new code.  Did
> that get dropped?
> - the 3.0 user_homes module uses gallery_ready to redirect the user to a
> new location before the request occurs - I think we can still do that in
> the 3.1 gallery_ready
> - the 3.0 sso module uses gallery_ready to change the active user - I
> think the 3.1 gallery_ready works for that as well
>
>
>
> On Thu, Jun 20, 2013 at 11:06 PM, Shad Laws <sh...@sh...> wrote:
>
>> I tried playing with this, and now remember why we put it in
>> Controller::execute() - if we put it before the initial request generation,
>> we (unsurprisingly) don't have access to a populated Request object.  In
>> particular, this screws up Theme::load_themes(), which uses Request to
>> figure out if we're in admin mode or have an override.  It also screws up
>> our check for a robot user_agent - while it doesn't bomb the code,
>> Request::user_agent() checks against a still-unset value.
>>
>> A few options:
>> - hack Theme::load_themes() and the robot check to no longer need
>> Request.  While technically possible, this sounds messy... I don't think
>> it's a good approach.
>> - move a couple things out of the "ready" event, and leave them in
>> Controller::execute().  This gets the job done without major hacks, but the
>> fact that we need to do this in the first place hints that a better
>> approach would be to...
>> - have two events, one right before the initial Request and one right
>> after.  This is my current favorite approach.
>>
>> Next question: if we do the two-event option, what should they be called?
>>  Some possibilities:
>> - Before request: init (exact Kohana analog), routes (most common
>> application), bootstrap, before_initial_request
>> - After request: gallery_ready (current name), ready (shorter name),
>> after_initial_request
>>
>> Thoughts?
>> Shad
>>
>> On 21 June 2013 01:12, Bharat Mediratta <bh...@me...> wrote:
>>
>>>
>>> I think that's reasonable.  I've never been 100% happy with putting the
>>> "ready" event in Controller::execute.
>>>
>>>
>>> On Thu, Jun 20, 2013 at 3:44 PM, Shad Laws <sh...@sh...> wrote:
>>>
>>>> I like the idea of reducing the init.php's down to zero and putting it
>>>> in an event, and agree that trying to keep track of this isn't a good idea.
>>>>  In fact, we could probably just move the execution of the already-existing
>>>> "ready" event from Controller::execute() to either bootstrap.php or
>>>> index.php (just before the initial request generation).  I wonder - should
>>>> it be renamed "init" to make its analog more obvious?
>>>>
>>>> Then, we just add a Route override that clears out the Route list, and
>>>> use it in Module to activate/deactivate things as well as in the unit test.
>>>>
>>>> Thoughts?
>>>>
>>>> Take care,
>>>> Shad
>>>>
>>>> On 21 June 2013 00:12, Bharat Mediratta <bh...@me...> wrote:
>>>>
>>>>>
>>>>> I've been wondering about that as well, but I wasn't thinking about it
>>>>> from the unit test perspective.  I was thinking more along the lines of
>>>>> activating and deactivating modules during a request's lifetime.  Eg, if we
>>>>> deactivate and reactivate a module several times, what is a developer
>>>>> supposed to do about their code in init.php?  Should devs guard against
>>>>> their code being called multiple times?  It feels messy to me.
>>>>>
>>>>> I think a better approach would be to minimize what goes into
>>>>> init.php, preferably down to zero.  We can leave the facility around, but
>>>>> since we're only using it for routes I think we could easily have an event
>>>>> hook which sets routes, then we can call that from Module whenever we add a
>>>>> module.
>>>>>
>>>>> If we want to be smart about removing routes when a module is
>>>>> deactivated (not essential for us to do right now, IMO) we could always
>>>>> track which routes were added when we call the hook and remove them when
>>>>> the module goes away, similar to how we do Graphics::deactivate_rules
>>>>> and BlockManager::deactivate_blocks...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 20, 2013 at 10:52 AM, Shad Laws <sh...@sh...> wrote:
>>>>>
>>>>>> Hey Bharat,
>>>>>>
>>>>>> It looks like, except for the REST-related unit tests I'm still
>>>>>> wrapping up, the only tests left are controller auth and XSS - woohoo!
>>>>>>
>>>>>> I did, however, hit a minor snag.  I got everything running well and
>>>>>> passing, hit a reset button, and then everything broke with the REST tests
>>>>>> - crap!  After a bit of digging, I found the problem: the REST tests won't
>>>>>> pass on a fresh installation.  They only pass if you activate the rest
>>>>>> module, *then* run unit tests.
>>>>>>
>>>>>> The issue is the rest module's init.php file.  Like the other
>>>>>> init.php files (e.g. in tag), it's designed to run *before* the bootstrap
>>>>>> routes are defined.  That way, they get precedence.  However, if you roll a
>>>>>> fresh install (which has rest disabled) straight into a unit test, it bombs
>>>>>> - the bootstrap runs first, then rest's init.php later... and it doesn't
>>>>>> work :-/
>>>>>>
>>>>>> One thought I have is to override the Route class so we can clear
>>>>>> them and restart from scratch, then make the unit tests re-load them all...
>>>>>> but that sounds kinda hacky and flaky (e.g. what happens if an init.php
>>>>>> does something besides load routes?).  Any better thoughts?
>>>>>>
>>>>>> Take care,
>>>>>> Shad
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>