Samstag, 26. April 2008

Canonical Form for Content Hierarchies

I am still pondering the question how exactly a content hierarchy should be modeled.

In a previous post I mention the possibility to declare authorization facts in a hierarchy. Something is still bugging me. Similar to programming, I think that some informations should be considered as cross-cutting concerns (or aspects). David's Model also has an example where authorization decisions have an impact on the model. This bugs me.

Somewhere there lurks the definition of a canonical representation of a content hierarchy:

"
basic, canonic, canonical: reduced to the simplest and most significant form possible without loss of generality, e.g. "a basic story line"; "a canonical syllable pattern"
..."

This does sound right, doesn't it? A basic form of a content hierarchy should
  1. have the ideal relation of breadth vs. depth (ideal for the content model)
  2. only have the necessary node hierarchies/attributes
  3. still make sense
Those are non-mathematical requirements. The definition of a "Canonical Form" is interesting: while defining a canonical form via equivalency of a range of objects, it remains unspecific about how and when to define a canonical form:

"...
A canonical form may simply be a convention, or a deep theorem.
..."

The most important part is that other content hierarchies which are equivalent to this normal form are all connectible via an equivalence relation.

So the task at hand is to define a model which can act as a natural representation of the solution domain. As soon as this model is found, enhancements can be defined, while still being equivalent to the canonical form.

Well, still lots of questions open:
  • is it possible to define a canonical form for a specific use case (e.g. a blog)? Or would it be on an ad-hoc base?
  • what would the added benefit of such a canonical form be? The answer might be that extensions would be made vs. the canonical form. If the canonical form itself changes, it should trigger the changes to the other forms. Or at least depict the consequences the change in the canonical form has to equivalent representations
There might be another alternative to attack the problem of "hierarchy purpose overloading": as in programming, cross-cutting concerns might best be attacked by Orthogonalization. But this is another story ...

Samstag, 19. April 2008

RESTful Authorization Model Considerations

Considering the fact that URIs map to resources in a RESTful design, an authorization model almost automatically means a URI authorization model:
  • URIs are subject to authorization decisions
  • URIs offer a hierarchical authorization scheme
  • additionally, the limited list of allowed actions (verbs) leads way to a simple definition of ACLs (Access Control List), more or less the same as for file systems (read,write etc etc)
All in all this design is quite a non-event since it all fits together quite obviously.

One thing to consider is the old question of attribute based security decisions. A real world example is a blog where the author first checks the comments before publishing them. The attribute would be whether the comment already has been reviewed or not.

There are 2 possibilities to do do the authorization check in a declarative manner:
  1. either the ACL is attached directly to the resource
  2. or the resources (posts to be reviewed) are stored in another place of the URL hierarchy, e.g. '/comments/review' instead of '/comments'. The ACL would be attached to the directory instead of the resource itself (directory being a resource in its on right)
Both make use of ACL which looks something like this:

ACL(resource):
  • reviewer:read/write/delete (this allows to move)
  • author: read/write
Both possibilities have got their respective advantages. The second one seems to be easier, but has an impact on the hierarchy of resources. Is it allowed to define a resource hierarchy according to a cross-cutting concern like security?

Dienstag, 15. April 2008

Grails & GWT: an uneasy match?

Currently I am looking for the holy grail for AJAX-enabled Grails development. While trying out the excellent GWT-Plugin, something occurred to me: there are 3 programming languages involved: Groovy for Grails and Java/JavaScript for GWT.

One could argue that Javascript is transparent while using GWT. I would agree to a certain point with this, because I do not know how fast you need to touch Javascript in GWT.

Still this leaves me with 2 languages, namely Groovy and Java. While those 2 languages are very close together, this situation reminds me of a brilliant comic.

So why not use Groovy and Javascript, i.e. directly use one of the excellent Javascript frameworks? It does make more sense, since both are dynamic languages and both get more and more IDE support, namely in that one that costs some (you get the idea...).

Still: 2 languages is still one too much. Since Javascript is set on the client, this means to use, well Javascript on the server too. The guys creating the Sling framework for example do exactly this: it is up to you to use the Sling API on the client or server-side. I am not sure wether the code is 100% the same, but the general direction is given...

I still go with groovy, call me old-fashioned...

update:

Maybe the strangest thing in GWT/Grails combination is the fact that everything sent to the client has to be IsSerializable. And has to be retrieved via a Service.

Contrasting this with the direct use of a JSON builder which creates a format directly consumable by all Javascript libraries. Nothing beats

render DomainClass.list as JSON


update 2:
The last "update" is of course complete crap, see the comments! I was still in a kind of prehistoric knowledge level, GWT-wise.

Samstag, 12. April 2008

Dont puck with me, Vista!

This is a rant. Nothing hightech in it, except Vista.

Lately, while writing an email, my MS Vista did a spontaneous reboot. With no apparent reason. Well, fact is, that this doesn't happen often. First I mainly game on MS Vista and do the real work on Ubuntu and second Vista is stable on my system.

Now, perhaps I haven't read a message or just clicked away a message box, might be. After reboot it was clear that some patches had to be applied. Ok, why reboot and stuff, yeah, whatever, it's Windows. But the fact that a system has got the balls to disrupt my work in such a manner is sign of a huge arrogance and a non-willingness to listen to and care for endusers. It is my computer and you don't do reboots without an explicit ok from me, dammit!

It is kind of saddening, because Vista is imho not as bad as it is being made. And securitywise it seems to play in a complete other league than the previous OS's from Redmond. But somehow Microsoft really manages to not be liked by me, although I really try hard :).

Mittwoch, 9. April 2008

Groovy as a First Programming Language

I am sure that this question has been raised more than once with other languages:
How does Groovy fit as first language to learn?
Same question could be asked for (J)Ruby, no doubt. It's too long ago for myself (yes, I admit that I started professionally with VB 5.0, so what? :)), but I do not see any showstoppers. Let's compare Groovy to other languages (purely subjective)
  • vs. C: C is cool for a look under the surface, but, ehm, as first language?
  • vs. C++: hardcore. Sooo hardcore. But I guess for someone who wants to get (at least) his/her hands dirty, it surely is a worthy choice.
  • vs. C#: I can't say much there, I do not know the language.
  • vs. FORTRAN: hey, don't dismiss that F-word :)
  • vs. Smalltalk: Smalltalk still seems to be one of the cleanest OO-language, and using something like Squeak, why not? Problem there is imho the transition to production
  • vs. Java: well, tough call. Java has got one big beginners friend: the compiler. I think this outweights the advantage that Groovy the language has over Java. On the other hand, it might be instructive to learn how to test a program the same time as writing the program itself. Also: too much IDE-help might be wrong at the beginning
I might test it with a workmate very soon. Have to check that Fortran-Compiler ...