DLM Intro Video

By Andrew Petro
January 17, 2008

In which I ease into slidecasting with a simple introduction to the DLM featureset.

Please bear with me as I ease into screencasting (podcasting?). This is an early foray into recording voice with a slide deck. It's viewable and I think somewhat informative, but production quality is low as I continue to experiment.

I'm very excited about getting more into podcasting as a way to communicate about open source software in higher education, inspired in part by having had great fun at PodCampAZ this year.

For better viewing, view directly on YouTube

(This presentation looks a lot better as hosted at YouTube rather than as embedded here, so I encourage you to hop over there to actually view it. More on that subject, and better technological answers, in a future post.)

Also, the audio is oddly out of sync with the video, such that typically it's showing one slide behind what I'm talking about. I haven't figured out yet how I broke that, since it's correct in the Keynote recording and in the resulting Quicktime movie.

Transcript

Hello. I'm Andrew Petro, with Unicon.

This is a simple introductory screencast on basics of DLM. DLM is an alternative to ALM. DLM stands for "distributed layout management" and it derives from Sungard Higher Education's Luminis product. DLM was open sourced and merged into the core open source uPortal project primarily through the efforts of a man named Mark Boyd who really did a fantastic job with that. So DLM is now a preferred alternative to ALM and has been present in uPortal since version 2.5.0.

The core concept of DLM is to make available pushed fragments that are managed as the layout of fragment owner meta users. So, what is DLM? Well, various inputs, really two inputs, come together to form an end user's layout. An end user's layout consists of the fragments that come from fragment owners mediated by declarative configuration of the audiences of these fragments, who it is that will be viewing particular fragments based on their group memberships or user attributes or what-have-you, as well as applying personal preferences whether those be entirely new layout content (tabs) that are managed by the end users, or whether those be modifications to fragments that are received from DLM within the bounds of restrictions on what an end user is permitted to do by the fragment owners through that declarative configuration.

And so to take an example: this is an example that comes from a presentation of uPortal status once upon a time at a JA-SIG conference. Suppose we have a library tab. Whether that tab's going to be a tab or a fragment depends on which layout management scheme we're going to use, but conceptually, suppose we have this tab. This is the sort of thing that was in YaleInfo portal and that's where this imagery comes from, from an existing slide deck that I presented once upon a time with Eric Dalquist at a JA-SIG conference. But here we have a lovely library tab, you can certainly be proud of this user experience here, where there are links and search and an indication of subscriber account information and news from the library. Really, it's a beautiful library tab. Suppose that new functionality becomes available through the efforts of library systems programmers: let's say we're going to have a channel that indicates where various libraries are going to be open and it might have oodles of controls and end user preferences as to which libraries we care about or it might not, none of that's really important to the story, I'm just trying to justify that plethora of buttons in the upper right there. Anyway suppose we have this new functionality that we'd like to include in this tab, the library tab plus. That is the story, the use case that we're coming from here.

So, under traditional, simple layout management under uPortal, given a particular user attribute mediated by the person directory system, the portal determines which template user to base a particular user's layout upon. Suppose that end user, using the features of the portal, expresses some personal layout preference, that is what is conveyed by that lightning bolt there. It might not even be to the library tab, they might express a layout preference somewhere else in the portal, but they express some preference such that they're not merely consuming their template anymore, their layout does not merely consist of a pointer anymore, it rather consists of a copy of the template layout that has been modified to become their personal layout. Well, under simple user layout management we have that template on the left and we can go ahead and update that template. Those users that have expressed no layout preference, whose layout consists only of a pointer to the template layout, they will enjoy the new channel on the library tab.

However, those users who have taken advantage of the capabilities of the portal, those who have expressed a personal layout preference one way or another at some point, the template for their layout may be updated in wonderful ways to include new channels such as this, but they will not experience that change. They have a couple unattractive choices. They could somehow otherwise become aware of this new channel and manually make that change to their own layout, or they could clobber whatever changes it is that they've made that presumably they value, that may be why they made them, in order to get back to a default user experience, their template layout, and then they would receive the updated version of the template. So really, a couple unattractive stories here under simple layout management. But it is simple layout management.

Enter Distributed Layout Management, where instead of using SLM template layout technologies, in DLM the template as it were is instead a DLM managed fragment that the end user receives because they are among the audience targeted by this fragment rather than by a magic username in PersonDirectory configuration to map them to a template user this user is part of a group or has the right user attribute or otherwise meets the audience requirements for a DLM managed fragment representing this library tab. And so there's a dynamic template. And again under DLM while you can choose to lock things down administratively such that users can't change the layout and content and so forth of the particular fragments they are receiving, say this library fragment, you can prevent them from making changes you could also choose to allow them to make changes or rearrange things or add additional content or RSS feeds or whatever it's going to be, to customize their layout to make it their own.

And so under DLM what happens where on the left as you see the template has changed where we've gone in as a layout owner and added the channel to the layout fragment.

Well, under DLM, even if the user has modified their layout, has expressed a personal layout preference, even if they've expressed a preference on this particular fragment some way that was allowed through the configuration of the permissions on the fragment configured by the fragment owner in the first place, even if the end user has taken advantage of all those features, you can still, as the fragment owner, add in this new channel and have it become part of the personal layout that is eventually experienced by the end user. It intelligently merges the updated fragment that's centrally managed with the end user preferences and modifications within the restrictions of what is allowed so you get this aggregation, this merger of your desires and the central changes, so that when the library has an improvement to the layout to be made available to end users, this can actually be made available to the users so they can enjoy this new functionality without having to engage in manual heroics to change individual layouts in an exceptional way to receive this new content.

If you have any questions about DLM, this is the sort of thing that I love to talk about, and I expect to learn to do some more screencasting. You can contact me at via Unicon's website and I'd really encourage you to visit the Unicon website. Thank you so much.

AttachmentSize
dlm_basics.ppt602 KB

Your Blogmaster:

apetro's picture

Andrew Petro

After graduating with a B.S. in Computer Science from Yale University in 2004, Andrew stayed on to serve his alma mater as a casual systems programmer with the Technology & Planning group. His interests include automated software testing, application frameworks, and electronic security. Projects in which Andrew has been involved include the Central Authentication Service, YaleInfo Portal (Yale's uPortal implementation). and the Jasig uPortal project. Andrew currently serves on the Jasig CAS steering committee, has been the release engineer for uPortal, and has been published in the Communications of the Association for Computing Machinery on the topic of electronic voting. In spring 2006 Andrew joined Unicon full time, serving roles since then including technical lead and Cooperative Support developer.