[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfw] Re: Session Package - Keep or Drop



We're talking a version of Framework code that if we're lucky the CMS will be using in 2-3 years; the odds of CMS 3.x consuming Framework 2.x code are pretty nil.  So I honestly don't think a legacy layer style approach matters too much for a code base where realistically I might be the biggest consumer.

As for the PHP minimum thing, separate topic, but I'd be aiming for 5.5 minimum if you wanted to slap an arbitrary minimum on the code as the *nix LTS distros are using it or 5.6 it appears, hosts are finally offering 5.5, 5.4 EOLs this year, and there isn't anything I'm aware of in 5.6 screaming for our attention.  Again, it's a decision we'd be making for an implementation 2-3 years in the future.

On Sunday, May 3, 2015, Andrew Eddie <mamboblue AT gmail.com> wrote:

On Monday, 4 May 2015 01:37:49 UTC+10, Michael Babker wrote:
Thoughts?

I think "it depends" on a lot of different factors including, but not limited to, usefulness of the code to the CMS vs usefulness to developers needing more recent versions of PHP. If it was me I'd be coupling the minimum desirable version of both Framework and CMS to lowest supported version of PHP - I digress.

I think the solution is one that should be applied to most low level packages. First, define an suite of interfaces for session management. Perhaps the namespace is something like \Joomla\API\SessionInterface

Now you can do a number of things:

* Do a backward compatible refactoring of the existing Session package to comply with the new interface, and keep the CMS running on its out-of-date PHP code (but allowing you to instantly plug-and-playing any other compatible session management solution on a per-install basis).
* Create a new Session package built right in PHP 5.4/5.5
* Allow a third-party to integrate a session package from another vendor (they might be trying to bind Joomla to an existing application built on Symfony perhaps) into their Joomla Framework app or even Joomla itself (if you propagate the changes to the CMS, which I think would be a really good idea).

As for coupling to the Application package, at worst it only needs to be coupled to the session interface (and even then that should be optional). However, a better approach would be to borrow the concept of "middleware" for the application (basically adding a Command pattern to replace some of the event triggers), where a session handler is merely a piece of middleware that the application loads (but is not tightly coupled to). That topic, however, is probably one for another thread.

Anyway, those are my thoughts.

Regards,
Andrew Eddie

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.


--
- Michael

Please pardon any errors, this message was sent from my iPhone.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.