incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Bergius <>
Subject Re: [zeta-dev] Introducing myself
Date Thu, 25 Nov 2010 18:03:54 GMT

On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt <> wrote:
> we have some very strict guidelines here in order to ensure a consistent
> feeling for all of our APIs to the developer. So, we would expect to you
> change the classes to our naming and interface guidelines before they
> can become a component.

Certainly. My current plan to ensure API compatibility to the Midgard
end of things is to keep the old libraries there as "proxies" to the
functionality moved over to Zeta components and naming conventions.

> That sounds great, especially contributing routing algorithms back.

Routing, configuration, templating. Lots of places where we could add
our way of doing this as another MVCTools option.

> You could also take a look at how Arbit [1] uses its own, more advanced,
> implementation of the MvcTools interfaces. I like its implementation
> quite much.

Thanks! I certainly will.

> Our database abstraction is fully based on PDO and our handler classes
> actually extend PDO. So I doubt this would work, or am I wrong?

In this case you'd have handlers that don't need PDO but provide
compatible functionality. But this is probably not the first priority
for us anyway...


> What do you actually do in your DB abstraction? Maybe that Midgard could
> benefit from using our query abstraction?

Mainly the possibility to run PHP applications built on top of Zeta
database functionality with Midgard as the storage layer. This would
give you additional benefits like replication.

Here's the Midgard query interface:

> So, the AppServer basically implements a HTTP server in PHP? Or is it
> more like SRM?

It is a persistent PHP application server, but one of the interface
options it provides is HTTP.

> I was more thinking of having a component which implements the
> repository pattern [2] in some way and provides back end abstraction for
> it, so you can seemlessly replace the implementation (e.g. a relational
> database, a couch DB, JSR-170, Jackalope, …).

Sounds interesting, yes. But indeed, JCR should provide some pointers
on how to build such repository interface. Other option is CMIS, but
that seems quite overcomplicated approach.

You may want to look at this:

> Toby


View raw message