Re: [VOTE] retire zeta components from incubation
Hi, On Apr 20, 2012 11:26 AM, Tobias Schlitt tob...@schlitt.info wrote: sadly, I did not find time to look into all this stuff. This also seems the reason that Zeta is dying: Time lack. I'm a bit sad, that Zeta is being closed down, but I think that it's the logical way to go. I think the important part is that PHP is finally starting to have a reasonable infrastructure for having a proper ecosystem: * Composer for dependency handling and easy library publishing * PSR-0 for standard autoloading * GitHub for collaborative development * Travis for continuous integration These four combined make it much easier to publish simpler, more decoupled libraries that just works. Node.js has a very similar infrastructure with NPM, and there indeed this has produced hundreds of compatible modules that are widely used, and that don't need any sort of monolithic project governance structure. I think there is still a place for an effort advocating library interoperability, quality and coding standards. Zeta could be that, but it needs to be part of this new ecosystem, not something standing outside of it. Toby /Henri
Re: [zeta-dev] The Piwi Framework
On Thu, Nov 3, 2011 at 3:48 PM, Christian Grobmeier grobme...@gmail.com wrote: But it seems, there is less interest. Don't know whats wrong, but it seems the PHP world is overloaded with frameworks. It seems, even a high quality framework as Zeta does suffer from this fact. In general, PHP has too many frameworks, and too few reusable libraries. I think for AZC it would be better to position itself as a managed collection of high-quality libraries than to try and position as a framework. After all, Zeta components can already be used outside of Zeta-managed framework code (for example, both Midgard MVC and Symfony2 have integrations with the Workflows component). Which brings me to another point I wanted to take up. How about packaging and distributing AZC through the new Composer system? That would make the Zeta components quite accessible and easy to depend on: http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/ Christian /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Jabber: henri.berg...@gmail.com Microblogs: @bergie
Re: [zeta-dev] The Piwi Framework
On Fri, Nov 4, 2011 at 12:35 PM, Fabrice PICCINALI f.piccin...@fazae.com wrote: And what about pear ? pear install zeta It is well-know, easy to use and you can have your custom depot. PEAR is ok for end users, but quite a pain for developers. It also assumes a global installation of packages, while Composer installs everything into your project. Way easier when you have multiple projects on a machine. Composer also generates an autoloader for you. -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Jabber: henri.berg...@gmail.com Microblogs: @bergie
Re: [zeta-dev] PHP based build system : Phing VS Pake
Hi, On Tue, Apr 12, 2011 at 6:49 PM, Gaetano Giunta giunta.gaet...@gmail.com wrote: As I proposed pake in the 1szt place, no need to assert any more that I like it enough. +1 from here as well. We use Pake anyway for Midgard packaging and installation. So at least Zeta Components have already been installed on a bunch of machines via Pake ;-) /Bergie
Re: [zeta-dev] PHP based build system : Phing VS Pake
On Tue, Apr 12, 2011 at 11:31 PM, Christian Grobmeier grobme...@gmail.com wrote: And while we are at it, consider to join the incubator.apache.org with pake. I am pretty sure there are some supporters around. I wouldn't mind seeing Pake and some other stuff from Alexey - like the AppServer in PHP project - under the Apache / Zeta Components roof. At least AiP is PHP 5.3-only, though. That might be an issue? BTW, here is a bit more complex Pake example, the Midgard MVC installer we use: https://github.com/midgardproject/midgardmvc_installer /Henri
Re: [zeta-dev] Proposal: Location component
Hi, On Fri, Nov 26, 2010 at 4:05 PM, Derick Rethans der...@apache.org wrote: You surely would like to call this a point instead? Also, are you thinking of only doing WGS-84 here? WGS-84 only for now. But agreed, Point makes more sense. Bounding box at a radius ... that doesn't make sense. A box is not a circle :P True, not the best wording there. The edges of the bbox are at the end of the radius. All of those services provide information in a slightly different way though. Especially with admin-levels. There ought to be an abstraction for this. Certainly. - Obtaining the location through Google's geolocation services: http://talks.php.net/show/maps-afup10/18 and http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac addresses). - Skyhook also provides an interface. Sure, why not. Maybe not in the initial version but would make sense to add. There are some special scenarios where talking to GeoClue would also make sense. Derick /Henri
Re: [zeta-dev] Proposal: Location component
Hi, On Fri, Nov 26, 2010 at 7:45 AM, Christian Grobmeier grobme...@gmail.com wrote: this component is currently GPL code. This is not compatible with the AL. Will this change? Are you the sole copyright holder for this component? Any code we submit to Zeta will of course have its copyrights transferred to ASF, and licensing changed to ASL. In cases where I'm not the sole owner we will handle the necessary CLAs with the other participants. Christian /Henri
Re: [zeta-dev] Proposal: Location component
Hi, On Thu, Nov 25, 2010 at 7:32 PM, Tobias Schlitt tob...@schlitt.info wrote: I'm not sure if it is a good thing to couple additional data to a spot from scratch. Wouldn't it be better to keep this part open to the user, so that he can extend it to fit his needs? User can of course implement another way to represent locations, but there is a quite standard DMS representation that I feel should be provided by the library. Internally the library keeps all coordinates in DD system. Third thing we should probably support is DM. All coordinates we handle are in WGS-84. http://www.sunearthtools.com/dp/tools/conversion.php Geocoding is a service for converting human-readable locations to actual coordinates (spots). I'm not sure, if the service based stuff fits into a base component, depending on its focus. I would imagine that the pure Location component should only deal with mathematical representations of geo-data and maybe leave the geo coding parts to a tiein. Geocoding could be a tiein, but generally it is quite a common part of geolocation services on other platforms. I'm sort of following GeoClue as the reference implementation here: http://en.wikipedia.org/wiki/GeoClue I would draw parallels between different geocoding services supported in this component and for example different feed modules in the Feed component. AFAIK Derick has also experience in the geo location area from his latest work with OSM. So I CC him explicitly to get involved here. Great! Additional contributions and ideas are certainly welcome here. That is after all the whole point of moving the geolocation functionality from Midgard to the wider PHP ecosystem :-) Toby /Henri
Re: [zeta-dev] Autoloads and autoload file
Hi, On Wed, Nov 24, 2010 at 10:44 AM, Maxime Thomas maxime.t...@gmail.com wrote: I've got a small reflexion about the base mechanism of ezcBase that allows us to add an outside repository of classes [1]. Sounds like a good idea. A common complaint about PEAR packaging from for example Debian Policy is that you get PHP classes coming from native packages and PHP classes coming from PEAR packages jumbled together in /usr/share. If we want to be compliant with their policy then a normal deployment would have multiple roots, for example like: /usr/share/php/ZetaComponents /usr/share/php/MidgardMVC /usr/local/share/php/MyCoolApp Max /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Autoloads and autoload file
On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad o...@ez.no wrote: For production environments it makes sense, and we have been toying with the idea of adopting the scripts to also create a similar list, which could work with components. In regular situations you probably need two setups: * Production: Zeta Components and other classes coming from PEAR or native packages (I'd love to see Zeta in Debian as soon as there is an official Apache release) * Development: Zeta Components and other classes coming from various Git/SVN checkouts The paths are likely to be quite different in these two scenarios. For production setups the relevant Debian policies are quite interesting. I recently packaged OpenPSA (a Midgard-based business management suite) to Debian and the policies made things quite clear: http://webapps-common.alioth.debian.org/draft-php/html/ http://webapps-common.alioth.debian.org/draft/html/ Ole Marius /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt tob...@schlitt.info wrote: The first doc should wrap up why such a library is needed and which use cases it should satisfy. The idea here is that we first gather all potential requirements before discussing a flexible design for the component. As you already have working source code, noting down the requirements you had in mind should be easy. Ok, will do. Expect to see this mail today or tomorrow. Finally, when the design has been discussed here on the list, you can start adjusting the code to the result of the discussion. It might be, that this requires some refactoring to keep the new component open for further extension (open-close-principle) and some class name changes. Certainly. The names are now all midgardmvc-prefixed, and we use the classical Midgard underscores-instead-of-CamelCase policy there. http://www.midgard-project.org/documentation/concepts-midcom-specs-components-styleguide/ We already have MvcTools, which provides interfaces for implementing a clean MVC and a dummy implementation of these interfaces. So, adding a second MVC component does not sound reasonable to me. Otherwise we will end up like PEAR. But maybe our MVC component can profit from the Midgard MVC somehow? Yes, looking a bit more at MVCTools I think it is better to look at using some of the classes there in our MVC, and contributing some alternative implementations (like our route system) back to MVCTools. This needs a bit more thought. * Midgard provider for the Zeta Database layer * Midgard provider for the Zeta authentication layer I'm not sure how this would fit into Zeta Components themselves. What exactly do you imagine? Just like you have Database implementations for MySQL and Postgres you could have one that talks to database via the Midgard abstraction. * Maybe Alexey's PHP Application Server: https://github.com/indeyets/appserver-in-php I'll have a look at that. The title sounds interesting, though. :) It is indeed quite cool. You have a persistent PHP process which can help to make things quite fast (though it means you really need to know request isolation), and you don't need to mess with setting up a web server. I use it for all my development servers, though not yet in production. Alexey will be visiting us next week, so I'll pitch the idea of Zeta to him. The discussion about having a Repository component already came up once in a while on the old eZ Components list. I'd love to see a generic and flexible repository component for Zeta, but this must be very well thought out and maybe splitted up into several tie-in components. That would be great. You already have some repository-related functionality in Zeta, like Document, Tree, etc. so the question would be mostly tying those together, with some Midgard repository concept added to fill the gaps. It would be interesting to get some input from the Jackalope (https://fosswiki.liip.ch/display/jackalope/Home) guys as well. Toby /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
[zeta-dev] Proposal: Location component
Hi, As discussed in my introduction thread[1], I'd like to propose for the Midgard MVC location library[2] to be contributed to the Zeta Components stack as a new components. As a first step, here are the initial requirements for a location library. Introduction The purpose of this library is to make it easier for PHP developers to work with geolocation. Geolocation is one of the emerging trends in web development, with new possibilities rising from browser geolocation support. This library focuses on dealing with actual real-world locations and relations between them, not with map visualization. Requirements In the initial version the location library should only deal with geolocated points. To build full geoinformation systems there will be need for lines, connections and areas, but these can be added in later iterations of the library. The library should provide the following services: Spot A spot is an actual location on a map. This consists of WGS-84 latitude and longitude. Optionally spots may have an altitude, timestamp, accuracy and a human-readable description. Spot should also be able to calculate distance and direction to other spots, and to provide a bounding box around them at a given radius. For display purposes spots also need to provide a way to convert them to pretty-printed human-readable coordinates. Geocoding - Geocoding is a service for converting human-readable locations to actual coordinates (spots). There should be an interface for geocoding utilizing various online geocoding services like GeoNames and OpenStreetMap Nominatim. Users of the component should be able to create their own geocoding service implementations. Reverse geocoding - Reverse geocoding is a service for converting actual coordinates (spots) into human-readable locations. There should be an interface for reverse geocoding utilizing various online geocoding services like GeoNames and OpenStreetMap Nominatim. Users of the component should be able to create their own reverse geocoding service implementations. IP geocoding IP geocoding is a service for converting an IP address to an approximate geographical location of the network. This can be used to locate users of a website for instance, in cases where browser geolocationing is not possible. The IP geocoding interface should be able to talk to at least HostIP web service to perform geocoding. 1: http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3caanlkti=2j_vhbrmc3x55ekkjojwtuq-=9ddms0zvn...@mail.gmail.com%3e 2: https://github.com/bergie/midgardmvc_helper_location
[zeta-dev] Introducing myself
Hi, Just to introduce myself, I'm Henri Bergius, one of the core developers of the Midgard framework. Midgard is one of the oldest open source web frameworks / CMSs for PHP. Midgard is a bit unique that in addition to the actual web layer written in PHP we have a content repository[1] that our system uses for all persistent data storage written in C (well, Vala in the next iteration, but C is what Vala anyway generates), with PHP-level access coming from a specific extension. Midgard has always focused on clean URLs, flexible templating, valid mark-up, integration with third party web services and high level of security. Personally I've been frustrated for a long time with the lack of a generic PHP ecosystem. As PEAR has largely stagnated, almost all interesting library and tool work happens either in complete isolation or within more specific ecosystems like Drupal, ZF, Midgard etc. I see the introduction of Zeta Components into Apache as a promising development that might be the beginning of a generic PHP code-sharing ecosystem[2]. As such, this is an area that both myself, and the Midgard Project in general should be interested in. So, how to get started? I guess the main thing is to get familiar with the existing Zeta Components, and then to start thinking of what of those we could use within our framework, and what parts of our framework could be contributed back to Zeta. Some low-hanging fruit could include: * Geolocation library: https://github.com/bergie/midgardmvc_helper_location * Our MVC framework: https://github.com/midgardproject/midgardmvc_core * Midgard provider for the Zeta Database layer * Midgard provider for the Zeta authentication layer * Maybe Alexey's PHP Application Server: https://github.com/indeyets/appserver-in-php If collaboration on some of these would sound good, I'll be happy to start the discussion in the Midgard end of things. 1: http://bergie.iki.fi/blog/what_is_a_content_repository/ 2: http://bergie.iki.fi/blog/php-finally_getting_an_ecosystem/ -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Hi,
On Tue, Nov 23, 2010 at 11:57 PM, Jerome Renard jerome.ren...@gmail.com wrote:
As you said, the very first thing to do is to get familiar with Zeta
Components.
But with regards to what you have already done with Midgard, I believe
it will be a piece of cake.
Yep. I'll do some experiments today, and start pitching the idea to
the rest of our community.
* Geolocation library: https://github.com/bergie/midgardmvc_helper_location
This one is really interesting.
Another that might fit into Zeta quite easily is the Forms library.
This also is a completely standalone package, though it has a helper
for autogenerating forms from Midgard2 schemas (which could be adapted
to Zeta database schemas too).
https://github.com/midgardproject/midgardmvc_helper_forms
http://www.qaiku.com/go/6nbc/
As these two have quite minimal external dependencies I guess they
would be the first potential contributions from us to Zeta. The other
pieces are a bit more interconnected, and some overlap with existing
Zeta stuff so probably it is best to work together first on the
simpler stuff and tackle those later.
If possible I would prefer getting only one MVC component in order to
avoid confusion
for users if they want to do MVC. This does not meant yours is bad at
all, it just means
that being able to compare differences with MVCTools [3] and your MVC
framework would
be ideal first. And then we could see how to manage with this, maybe
we could integrate
some parts of your system in MVCTools. This needs to be debated actually.
Agreed that multiple MVC implementations in Zeta doesn't sound like a
good idea. Actually, probably having any full MVC implementation there
doesn't make sense. Therefore the term MVCTools is a good choice, as
the project can provide common building blocks for different MVC/CMS
projects to implement :-)
On a quick look at MVCTools, Midgard MVC is conceptually, and in some
places also API-wise quite similar.
Here's the basic description of how our MVC works:
https://github.com/midgardproject/midgardmvc_core/blob/master/documentation/index.markdown
Some quick points:
* Routes work very similarly, though we use different URL mapping
syntax based on URI templates[1]. So this could be just another
MvcRoute implementation
* We also rely on a Request object, and use it for request isolation
(everything related to a request is kept in that object as we have to
support multiple requests within one PHP run)
* In Midgard MVC we have full subrequest support, so in your template
you can for example make a subrequest to display five latest news
items
* In our case Routing Information would also contain the matched
variables from the URL (so URL /news/meego/2 matched to a route
/news/{$category}/{$number} would provide array('category' = 'meego',
'number' = 2)
* Our routes are also used for generating URLs when applications want
to redirect or display links
* We do not require controllers to extend any baseclass as the
component interface is quite trivial
* In our case controller actions are named with pattern HTTP
verb_action name, so you can define separate action methods for
handling GET and POST (for example) for a route
* Controller's results in our case are just stored to a data array
in the controller, so actions don't return anything. In cases of
errors they're supposed to throw exceptions
* We have a concept similar to MvcTools Filters called Injectors. At
the moment you have only two of these: ones called after request has
been parsed but before controller is called, and ones after controller
has been run but before we go to templating
* Views is probably the area where our approaches diverge the most. In
Midgard the whole thing is run by template composition, where route
only provides aliasing information on how to handle element inclusion
in the template. We use TAL as the default templating system
Anyway welcome to the Zeta Components community :)
Thanks! The Midgard project has always been quite isolated from the
rest of the PHP world (though I guess many other similar projects are
also quite insular). Hopefully this collaboration can change things
:-)
Jérôme Renard
/Henri
1: http://tools.ietf.org/html/draft-gregorio-uritemplate-04
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.berg...@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
