What to do with the Cache package

[Andrew Eddie]

One of the backlog items for the Framework is to replace the existing Cache package with Louis's work that he did some time ago. The issue is here:

https://github.com/joomla/joomla-framework/issues/29#issuecomment-14787457

Also, to set the scene, the FIG group has been talking for over a year now about a standard interface for caching libraries to use.

I've done some work on Cache adding tests and fixing a few things in the code, but Florian put the question, why don't we just look at Doctrine's cache:

https://github.com/doctrine/cache

http://docs.doctrine-project.org/en/2.0.x/reference/caching.html

As it happens, I was looking heavily at that yesterday. I'm willing to consider the question. The advantages would be that the code is done and documented and has a richer feature set. The disadvantage is they don't have full test coverage.

The I think the practical options we have are to continue with Louis's cache so we can still "own" the code, or, we help Doctrine finish the unit testing, improve the documentation etc. They will be upgrading to the PSR as soon as it's accepted anyway so I think there might be some merit in consolidating our effort. It also has no dependencies like there are in other cache libraries.

If we did that, if would just mean that we would drop the Cache package altogether and just document that we recommend using the Doctrine cache.

Thoughts?

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[Amy Stephen]

I would give a quick yes if the only cache class was the old one.

The rewrite is very good -- I can see it as practical for many applications.

On the other hand, ... idk, nice to reduce inventory, I suppose. Have to think about that, I guess. There are definitely better candidates for retirement.

[Amy Stephen]

I think that a framework needs to have 80%+ of the basic packages most application frameworks have. (Cache, Database, Email, Log, Http, etc.).

I don't think it's important that each package is the best there is out there. For Logging, for example, I wouldn't try to give Monolog a run for it's money, I'd have a nice basic log package for Joomla -- then -- interfaces in place that make it easy to swap out the basic package for a more sophisticated version.

In many ways, Monolog is way too much for anyone, it would be good to see plugins for those various options. Meaning more isn't always better. It's more code to carry around and hope doesn't have security issues, and so forth. Basic, general purpose packages that do simple tasks in simple ways honestly is best for many/most people.

I kind of disagree with the notion that Joomla should get rid of a package because so-and-so has one with more bells and whistles. Makes more sense that Joomla keep it's pages aimed at general purpose use with high quality, excellent testing coverage, and then focus on flexibility at swapping out the standard package for other, using interfaces, bridges, whatever.

In all honesty, I see a lot of NIH finger pointing by projects who are saying "You should be using our code." I've asked, and I am not seeing many examples of packages they have thrown off the ship so that they can use that from another project.

IMO, a better way to look at avoiding a NIH complex is to make certain your core packages can be swapped out -- while, at the same time, you are providing for your core developers and dependent applications. That's the best of both worlds, I think.

Over time, I imagine projects will specialize and there will be some shedding of weaker offerings.

Anyway, that's my ramblings. Interested in hearing what others think.

On Tuesday, March 12, 2013 4:36:34 PM UTC-5, Andrew Eddie wrote:

[Andrew Eddie]

On 13 March 2013 16:59, Amy Stephen <amyst...@gmail.com> wrote:

I think that a framework needs to have 80%+ of the basic packages most application frameworks have. (Cache, Database, Email, Log, Http, etc.).

I don't think it's important that each package is the best there is out there. For Logging, for example, I wouldn't try to give Monolog a run for it's money, I'd have a nice basic log package for Joomla -- then -- interfaces in place that make it easy to swap out the basic package for a more sophisticated version.

The thing with logging is we have a PSR standard, so it's easy for us to design for that. But in terms of J\Log, it's really up to those who want to maintain it to keep it going. I have no issue with that but I think it's also fair to say that Monolog is going to suit a good fraction of the types of developers that are going to be attracted to the Framework.

 

I kind of disagree with the notion that Joomla should get rid of a package because so-and-so has one with more bells and whistles.

I don't think it's just that. For me it's about how complete those bells and whistles are and if I'm the only one "volunteering" my time for the package concerns. I'm going to choose the path of least resistance :)

 

Makes more sense that Joomla keep it's pages aimed at general purpose use with high quality, excellent testing coverage, and then focus on flexibility at swapping out the standard package for other, using interfaces, bridges, whatever.

So, this is where we swing back to Cache. I have done a lot of looking around and I've decided to put the effort into our own Cache. This is because the other offers have no more code coverage than we do, but I can also make Joomla\Cache natively Psr\Cache compliant as opposed to being a proxy to Psr\Cache. I think that will make it attractive to other PHP developers.

 

Anyway, that's my ramblings. Interested in hearing what others think.

Same.

Regards,

Andrew Eddie 

[Ronni KC]

For me its a matter of not reinventing the wheel.

If we dont add something new to the table does it make sense to make a package ourselfes?

If there is something out there used by multiple other systems etc. and we can jump on that bandwagon and spend our ressources on bigger fish to fry / more groundbreaking or unique ideas - does it then make sense to not go for something like Doctrines cache packages?

After all if we select our "fights" carefully i think we have a better chance of winning the "war" ;)

And in that sense - if we can free up ressources for more important things i think there is a whole series of things thats vital for the CMS also that would be more interesting to work on then keeping our own cache package if we dont add something new to it.

[Andrew Eddie]

Here's what I've done so far. It's compliant with the current PR for Psr\Cache (knowing that until it's accepted, anything could happen).

https://github.com/eddieajau/joomla-framework/tree/Cache/vendor/Joomla/Cache

I think it's getting there.

[Amy Stephen]

Just to be clear, though Ronni, in this case, we have the code -- this is a complete rewrite that will replace the old cache classes that are very coupled to the CMS. This new code is already written, provides a generic approach that can easily be used by other PHP applications. In my opinion, it's the quality of code that better represents the skill and potential of the project.

Will take a look, thanks Andrew.

[Elin Waring]

@Andrew

I think everyone who works intensively on a package has to understand that other people stepping in and helping in a leadership kind of way is not something that is going to happen much. You will get helpers but he fact is that individuals have to step up initially and when the starters of projects move on.  In this case we had Louis's work and now you have stepped in to finish it up and that's how it goes, there will be bug fixes and improvements but until there is need for another complete rewrite you shouldn't expect that someone else is going to come in and write thousands or even hundreds of lines of code. Code by committee doesn't work well anyway, but you just have to wait until someone needs to scratch an itch.  And if over time packages fall to irrelevance and no one cares enough to update them then they can be removed.  This is certainly true of all the external API packages but it is also true of packages like JCache.  If at some point we find that only 5% of people are using JCache  and 95% of websites using the framework are using something else and no one is actively maintaining then removing might make sense. In the meantime a large percentage of the web uses JCache and expects the Joomla Framework to provide it with a cache package and I think it should be supported. 

This is a project for people to code things they find useful and enjoy coding. It's not about a war or about other people telling you what you should enjoy writing or find useful  or about commercial dominance (although winning users and being able to say your code runs 3% of the web is certainly part of the fun).  It's about good code that people want to share with others. 

So if it makes you happy to code it and share it and the maintainers think it is good code, do it.

Eli n

[Andrew Eddie]

It's already done and in the main repo. It will need some minor tweaking when Psr/Cache is approved. 

Regards 

Andrew Eddie

--
You received this message because you are subscribed to the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-plat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Amy Stephen]

As an FYI, Symfony now appears to be opening the same discussion about whether to add a cache class or use Doctrine's.

https://groups.google.com/forum/#!topic/symfony-devs/EJr6XhawJTE