After the suggestion by Xavier, this wasn't all that hard. Witness RSS Streams for the Blog, comments of each entry and also one for each category of blog entries. All created on the fly.

Now if only I could figure out how to render timestamps conforming to RFC822 easily. Will probably have to write my own template operator or something...

I was wondering about the RSS facilities in eZ for a while now. While there are all nice and dandy for simple things, they fall short for more complicated things (like say providing RSS streams for the comments of a blog posting without creating the stream by hand) or, which is my personal thing as my blog categories are based upon object relation, the fact that a new object is related to some other object (which, in it's very essence, is what tagging is all about).

So one of these days, I want to address this two things and add RSS export that will allow on the fly creation of RSS streams (think rss/$parentnodeid and the module will export all child objects of parentnode) and the above mentioned tagging features. I'm not yet quite sure just how I'm gonna do it but it's not like that ever stopped anyone ;)

This has been due for a long time but I just never found the time...

The usual disclaimers about it being evil and broken still apply, though.

For my forum efforts I figured I should offer tracking of read/unread status of certain objects. Now obviously the KISS approach would be to have a table with and just regard everything in there as being read. However, this has something like m*n storage needs and likely wont scale very far. What's would for example happen on site with 10000 objects if a new user decided all old postings should be marked read for him? It would result in the DB growing by 10000 rows...

There must be a better a way (after all there nearly always is). The only really practicable way I can think of is a table with , i.e. whole ranges of read objects. But this also suffers of two problems: 1) there's no way to keep track of different versions of an object, so it's essentially only useful for site that have archive like functionality with no changes to objects once they are published. 2) it needs a lot more code to work (especially some code that goes and merges ranges if applicable). It's not so bad but the first issue can't really be solved this way I believe...

I wonder if the following would be of any use:

Right now, we can do attribute -> contentobject links (and backwards, of course).

How about doing contentobject -> attribute and attribute -> attribute? All this would take is another field in the relation table (and persuasion of ez devs to integrate such in ez 3.8 which would be the hard part ;).

Another idea would be to add a "boolean" (I know MySQL doesn't support it per se) field that says it is actually a bidirectional link and then have both object's see it as their "own" relation as well as reverse relation!

I couldn't update the site for the past few weeks: every time I tried to edit something, I'd just end up with the frontpage (viewing pages worked fine, though). I suspected it was ezurlalias' fault and after a lot of fiddling I was proven right: there was a wildcard URL alias (weirdly enough, using is_wildcard=2 whereas I suspect 1 being the normal way of doing it) for the root node. Which obviously caught everything but the urls that actually exist. Now I'd really like to know how that got there...

It's the time to let go, time to find and master new challenges, time to say goodbye to my first company.

I've learned a lot in the past 6 year but the profit margin in the market has become insanely small. The perhaps most important lesson of them all was that it is crucial to have an exit strategy ready for when it's time to leave a market.

The official note It's operations will be in good hands.

There's more to come one of these days.

Looking at http://blog.coomanskristof.be/2005/12/25/planning-a-customcheck-policy-limitation-hack/ I figured that Kristof is basically doing the hook where I could plug my own datatype in, without further kernel hackery. So let's hope he really does this ;) Turns out he sees some issues with policing read access due to the way how it is currently handled. A deep look at the code will be necessary I believe.

While the ezpublish permission system is quite flexible from an admin's point of view, it leaves a lot to be desired from an user's point of view. For example, a user can't decide himself (not easily, anyway) who should be able to read the object he just created. Even in the plain old Unix permission model he gets to chose that (obviously root can override that, but administrators are 1:1 the same in ezpublish) up to a certain extent.

Thus my desire to give this flexibility to users on an on off basis (obviously, in some cases you don't want to allow them this power, most likely when you're using approve workflows and things like that). After thinking about it for a while, I've decided that shoehorning a good model into the current permission system (like I did with ParentOwner which is comparably trivial) would be really really ugly and rather inflexible to boot. I then laid this to rest somewhere in the back of my mind until my interest in this got resparked when I read http://ez.no/community/forum/setup_design/make_robust_to_using_back_button_rather_than_cancel#msg90419 (the beginning of the discussion isn't quite related to this, but in the end it quickly converges towards this, in my mind anyway).

When I first thought of this I figured that using sections in a clever way would work (and most likely it would, for simple private/public features) but after some thinking I've decided against that. At some point it dawned upon me that a custom ACL datatype would be perfect for this, the only change in the kernel would then be a hack to recognize this datatype and let it override some of the permissions if it exists in an object!

Since the architecture is very flexible this way, I've been thinking that first I need to get the code stub to interface with the datatype into the kernel, after which the datatype can gradually be extended (obviously starting with a binary private/public option for reading, then writing, then adding something more like ACLs, possibly even groups).

I added features for an AJAX threaded forum (think threading like in good old usenet readers) and nested layout (like on slashdot) to advancedforum. Obviously, nested/threaded only works for topics that actually are created as trees so retrofitting it on existing discussions will have it look flat like it always did.