| uPortal developers meeting Systems and Computer Technology Corporation (Campus Pipeline) Salt Lake City, Utah, USA March 6 and 7 2003 Thursday March 6, 2003 IntroductionsInstructional Media and Magic: Jim Farmer (also representing JA-Sig) Michael Ivanov Justin Tilton iAssessment: Jeanette Hammock Scott McCarty Universities: Dan Ellentuck -- Columbia (groups and authorization) Alex Vigdor -- Columbia (wrote the Permissions Manager) Michael Oltz -- Cornell Howard Gilbert -- Yale (CAS and PersonDir, LDAP) Shoji Kajita -- Nagoya University, Japan (internationalization) Unicon/IBS: Nick Bolton (channel development and framework hacking) Steve Valero (similar work to Nick) Peter Kharchenko Ken Weiner SCT (Campus Pipeline): Mike Zackrison (has been heading up their effort to integrate uPortal into Campus Pipeline) Mark Boyd Jan Nielsen Keith Stacks Marlin Benson Josh Horner (will be taking over mgmt of uPortal integration effort) Ken: purpose of these meetings is to talk about new features coming up, collecting ideas and make a work list 2.1.x issues: [Ken Weiner]actually, not much new code in there since 2.1 The uPortal Bugzilla site lists bugs, and requests for new features. on 2.0.3, there are no more bug fixes that the main group will do. Because now there is already the 2.1 branch AND the main (equivalent to 'daily'), so that's already two branches to apply fixes to. Don't want to maintain three branches. Most changes in 2.1 have been to groups and permissions. Ken showed the Bugzilla list. Some things in there are old, some don’t even apply any more. We are still looking for someone to take over the database bugs from George Lindholm. Enhancements that have been requested by way of Bugzilla: a channel authoring document -- John Fereira has some material on this (Ken and friends send great thanks to John!) Implementing keywords into publishing and subscribing; (ability to attach Dublin Core information and search it) Debra Rundle asked for this a while back -- Alex said that the EntityPropertyRegistry could do that without having to modify the database. Publish and Subscribe Preview (Ken held off implementing this because of new interfaces coming up; besides, there was a request to make subscribing available as a servant) Subscribe to a node or category (that's part of Aggregated Layouts) Ability to publish XSL directly without going through stylesheet filters Implement all set methods of PreparedStatement in the RDBMServices class (was on George Lindholm's list) Internationalization A mechanism for channels to clean up (what does this mean?) Deploy XSLT stylesheets into one location. Right now they are being put in two places -- one in web document root, one in the class path. Theme and structure stylesheets are only ones in the web document root. Ken wants to change those to be in the classpath for the sake of consistency. This will require change to values in appropriate database fields. Why was it this way? Peter thought that stylesheets should be downloadable from the web, he said that as yet nobody actually needs this. Channel management servant. Andrew Draskoy wanted this. Channel Restart and Home button in title bar. (Home goes to initial state of the channel, restart is like the things in the bottom when a channel crashes) Modify a URL depending on user attributes; when you have a URL specified in the subscribe parms, this is some code that Yale has that basically substitutes some trait of the user (e.g. from LDAP) into the URL as a macro. The SSL issue. Ken reminded people to reference the bug number when you check the correction for it in to CVS. Exception handling request by Alex. He overrode the PortalException class to always print the nested exception. Never "gobble up" a PortalException in something else, because that makes debugging harder. What is the company "iAssessment" and what is their relationship to uPortal? It's a product for the K-12 market; state governments contract with them to make assessment tools for teachers to use. They have 150,000 actual users in their largest (California) database. They wrapped their existing tools into uPortal channels. They separately implemented something like aggregated layouts. They are going to face the internationalization issue this year. Issues with how it scales. They have 5,000 user logins a day and had serious performance problems; they have made improvements. They are running 2.0. Their users are not sophisticated enough to want to change the layouts. Howard: There's a hash table in the IPerson object. He got code from someone to handle more than one value per LDAP item, by changing the return value so it's not a String and using a Container of some kind. Howard wants to use a single String with delimiters in it instead, so as not to break existing code so badly. Alex: why don't you add a new method which someone could call if they would be able to handle more than one parm. Howard agreed to do it that way. Internationalization [Shoji Kajita]Shoji Kajita explained the status of his effort to convert the uPortal into Japanese, and also future plans: He has made uPortal framework "transparent" to UTF-8 in 2.1/2.0.3. Before then, such characters could not go into database, and such characters could not be displayed. Status of corrections to channels regarding this: CWebProxy fix is committed to CVS, CBookmark is reported in Bugzilla; CWebCT fixed but not reported. UBC Webmail fixed but not reported. CuCMS and some others not resolved. What languages has uPortal been requested to support? UK English, UK Celtic, UK Welsh, French, Swedish, Spanish, Japanese, German, will have Russian and Czech, eventually right-to-left languages. Framework changes for i18n have highest priority; channels less so. Internationalization of channels is less time-sensitive. Four issues: 1. UTF-8 transparency Framework level Channel level 2. Locale-aware runtime processing 3. Locale-aware channel development 4. Translation of Resources by Translators. In this presentation, he focused on point 2. As for point 4, Justin Tilton will follow Shoji Kajita's remarks with his proposal related to XLIFF (see below). 2.a. Locale-aware GUI i. In publishing channel ii. For users to select locale to be rendered 2.b. In rendering contents, we need to consider i. How to determine locale to be rendered ii. How to bind locale dependent resources iii. How to save locale dependent resources in RDBMS Proposal: when channel is being published, publisher specifies a default locale. He also wants to add an icon to the channel title bar (letter "L" on it) so the end user can set desired language for that channel. New "LocaleManager" class manages the determination of what locale the channel should be rendered for. The sources of the locale information: Language preference specified in web browser Language selection box provided by uPortal framework Channel dependent language preference External system like LDAP. Ken: there would be a site-wide property and then a property of the user profile. Back to Shoji Kajita: Binding locale-dependent resources "Build time" processing prepare locale-dependent XSL files minimize additional processing cost easy to implement -- merely change the path of the XSL files "Run time" processing parse-time translation in rendering process; replace all of locale-dependent parts in parse-time requires finding some method to minimize the impact on uPortal performance. Justin thinks that the run-time one may be too costly timewise. Database issues 3 new tables UP_LOCALE UP_CHAN_MDATA [metadata] UP_TYPE_MDATA [metadata] UP_LOCALE: a list of whether specific locales are supported. UP_CHANNEL: for each channel, what is its default locale? (if user does not specify language preference) New Columns UP_LAYOUT_STRUCT.CHAN_LOCALE UP_CHAN_TYPE.TYPE_LOCALE Locale Java Locale class uses two letters as language and country codes en_US, sv_SE etc. We need to use three letters if we support Celtic and Welsh (there are actually official requests to support that). ISO 639-2 Three letter language codes, ISO 3166 three letter country codes Java Locale class is documented to support two-letter codes; the doc says nothing about three-letter codes. There are special calls to convert the stored two letter codes INTO three letter, but there are (?) three-letter codes with no two-letter equivalent. As an academic project we have to have three letters. Java Locale is final, so you can't extend it. Arrgh! So we will have to write our own. But that won't work for a ResourceBundle which requires the built-in Locale class. (Welsh and Celtic are because Oxford wants to use uPortal for their library catalog) Suggested: find out how other people have solved this problem. Jim: 1. Find out if Sun (JCP) is dealing with this. 2. Talk to people at [e.g. Oxford] to see how it's being dealt with. In the database you'd have to put in both the 2 and the 3 character codes. Ken said we would have to go with making custom code for the present, and we have to save all three parts in the database. Then it was pointed out that the variant (third) field is implementation dependent, maybe we could squeeze some extra info in there and not need to put three letter codes in the "Locale" language field. Later in the meeting, Jan Nielsen demonstrated that the Java Locale class would actually work with 3-letter codes even though it is not documented to do so. If we can rely on that, there is no issue and no custom code is necessary to get around it. Peter: way to choose channel locale (listed from lowest priority to highest): portal-wide locale ("unless otherwise specified, this portal site runs in Swedish") User-specific defaults (1,2,3) User: "When I use this profile I want to see everything in English". Channel-specific choice by user. (either when subscribing or at runtime?) "I want to see this channel in Japanese." Originally each channel would have a default locale specified in the database, but as the discussion developed it was decided to handle that part a different way. Each level has a list, they are stuck together and sent to the channel; which then chooses, possibly using a framework-provided method (or writing its own method). So, the "channel default locale" is embodied as a method (algorithm) in the channel, not a database entry. Alex: suggested we not bother to have a "channel default", it works only if it takes precedence over the profile-wide one. Peter: The thing is, if the channel does not support any one of the supported or requested languages, then we need a default. Do we need a hard-coded list of supported locales, or allow everything? This discussion went on for quite some time. It was pointed out that specifying a list of locale preferences at each of several levels is a power user sort of thing. Peter facetiously: "Enter your IQ" Alex: "… or your tolerance to pain" . [and this would determine the complexity of the interface.] Jim pointed out there are portals where depending on the number of hours you've used it, it gives you more complex UI details. Justin Tilton spoke on "XLIFF and Internationalization":There exist translation tools to port applications. TRADOS to translate Microsoft RC files, KBabel to translate UNIX based PO files, and there is something called CATALYST.These companies are standardizing on XML Localization Interchange File Format, called XLIFF. A way to store localization information. It's a very young standard but has potential. Contains localizable content. Bi-lingual format (source and target). Metadata is included. Not for many languages in one file. Special Olympics 2003 is using XLIFF. Microsoft Content Management Server / Berlitz IT integration is using it. IBM's Domino Global Workbench is using it. Justin described a way that they are experimenting with using XLIFF during the build process to create multiple copies of XSL etc. files, each in a different language. Peter worked on this too; he gave a technical explanation of the build process and a language selection mechanism and the locale priority. For XML and XSL files the translatable units will be identified directly in the Markup and converted to XLIFF by a transformation, for text files (such as property files), strings will be extracted by a tool which Peter is developing and a skeleton file, and XLIFF file will be created. Then translators provide the translations by utilizing the XLIFF files and saving the new translated targets. The completed XLIFF files (with the target translations are used in combination with the original XSL and text skeleton files at build time to create localized files. Jim extracted three points from the internationalization discussion: This is not an immediate issue; we don't have stuff ready immediately and bunches of people to do the translations. Plumtree and Vignette do this. Ask them. It's complex and messy. Aggregated Layouts [Michael Ivanov](Monday afternoon, first session.)actually presented by Peter Kharchenko mostly, and Michael made some comments about classes and so on. The Aggregated Layouts feature will provide an ability to delegate portions (called "fragments") of a layout to different groups, possibly with restrictions on editing. With this feature, the content of a layout is a collaboration between end users and people who have authority to push content. Pushed content -- prearranged incorporation and updating of content in a user's uPortal layout. Pulled content -- self selected incorporation of content (including content fragments) into a user's personal layout. Concept of "Fragment Priority" So there will be attributes on how early in the list of tabs a fragment will be displayed. The priority determines the orderings of siblings. Could control "leftness" of channel or tab ("rightness" in right to left languages?) and "depth" for channels. Each entity who can create fragments, will have a range of priorities that that user can assign to the fragments they publish. It is possible to assign priorities and wind up with an undesirable situation. Another kind of restriction: put channels and nodes in groups also; then you can make choices like "this node can contain only nodes or leaves from this group." Michael has been implementing Add, Move, and Delete. The existence of pushable and pullable fragments complicates the implementation of these. If a fragment is changeable by user, what happens is the "change" makes an "audit trail" which is saved, and the "change" is applied whenever the session begins, so that it doesn't actually change the default; this aspect of the feature is not yet implemented. The other kind of change is for the central staff to change it; all users see this change. Michael showed a UML diagram of the classes. UserLayoutManager is the most important existing class to modify. Because Campus Pipeline already had an implementation, Peter made it pluggable so we could have our implementation and they could have theirs. This was introduced in 2.1 by adding the IUserLayoutManager interface. Some of the code has come into 2.1, but it's just enabling later work; aggregated layouts themselves do not yet actually exist. There are several classes to represent the restrictions (e.g. "must be at depth 1", etc.). New fields in UP_LAYOUT_STRUCT with information about neighbors, parents, children, next and previous nodes for a given item. There is also a UP_FRAGMENT table, similar to UP_LAYOUT_STRUCT. There is also a new UP_LAYOUT_FRAGMENT_PARM. The STRUCT and FRAGMENT tables differ primarily in where the content comes from, user specification or externally. The regular STRUCT table has fake nodes in it that tell where the FRAGMENT nodes fit in. Two types of restrictions, one is simple, the other kind more complicated. So far there is no UI to do the subscribing to fragments, nor even a UI to push. To push content, they make an XML file describing what is going to be done; this file has some restrictions specified in it (it also lists what groups will get the new content put in them). Then you run a batch program to actually roll it out. They implemented it this way so they could test the Add method without having to implement a UI. When adding a fragment, it checks the restrictions and then inserts into the appropriate place in the regular layout. Three parts: 1. IUserLayoutManager 2. actual implementation of that interface 3. the XSL at the end that doesn't work any differently from earlier. The current User Preferences interface would have to be different: you have to know what channel or fragment you are adding, before you can pick where it goes (because of the restriction specifications). In the most primitive release publishers will have to author those XML files. Jim asked "what lessons were learned?" The Campus Pipeline guy said that the moving of fragments (the change 'audit trail') was by far the hardest part. Ken wanted to know how far along we are; when will we get to some place where we can distribute something? Ken asked if the Aggregated Layouts guys are keeping themselves updated to the current version of the code. They said they haven't been looking much because they don't think there's much interaction between the code; Ken is concerned that they are falling out of sync. He wants them to check the code into the main branch even if it is not functional, to forestall such problems. The obstacle to this is that there are database changes -- but the checked code can use different names for the new tables. Dan said -- checking in would also verify that the Aggregated Layouts code requirements for jar versions are in sync with the main branch. [after a break] Layout management [Justin Tilton]This is the new preferences editor that is built in to a mode of the actual user layout. When you click "Preferences" it changes over to this.A drop down under left of tabs chooses anything that requires multiple steps to do (the "…" kind of things). The tab names become text boxes; several icons appear under each tab name to change the tabs. Column actions are: widen by 10 percent, narrow by 10 percent, or remove (the whole column). There are arrows in the corners of each channel to move it. Peter, knowing the Aggregated Layouts design, says this won't work, because some channels won't be moveable. And not all destinations would be permitted either. So the arrows in the corners might not be on this initial screen. An expanded channel-editor and redesign of some screens. Searching through the list of all channels for one you want. Subscribing to multiple channels at once? Or just able to preview more than one at once? Justin also quickly showed some slides from an early Aggregated Layouts discussion, about how the user interface might work. Should a fragment creator put the desired stuff into their own layout and then say "okay take this portion and make it a fragment"? Or create fragments separately in a completely different mode? Alex: There isn't a reasonable way to edit restrictions if you do it the first way. Jim suggested in that case the editor person 'right click' on the fragment to edit restrictions. Justin has no robust mockup of restrictions editor. There was a lot of back and forth on which of these two ways it should be done. If the fragment editor is a separate thing, then the fragment creator person should be able to pretend to be a student, for example, so they can see what it looks like to the end user. The design of the code so far, requires a fragment to be contiguous when published (for example, can't exclude one channel in the middle of a column), but it can span more than one tab. Someone said that it's more intuitive if one creates the fragment in their own layout. Ken: [that's not relevant because] if someone is in charge of editing a fragment, then that's their job. If there's a particular special way to do it then they will have to go and find out how to do it. Peter: How can we leverage our work on editing normal layouts into editing fragments? Ken: Can't you have a "FragmentUserLayoutManager" [class] as an implementation? Ken: For the next release, let's not do the user-interface stuff now, just get the methods actually working. Create the fragments using XML and a batch process, so we can at least get something out the door, instead of waiting to have a finished, designed user interface to edit them with. That would push off the next release too far. Michael Ivanov agreed with this approach. The consensus is that the next release is still 2.x, not 3.0 as yet. Jim: What impact will WSRP implementation have on the database format of the installed base of users? Ken: said no impact, nothing different. Jim: Database upgrades have a significant impact on, for example, iAssessment, because they have such a large installed base. Friday morning March 7, 2003 Groups and Permissions [Dan Ellentuck]Outline: Changes between 2.0 and 2.1 and why they did them. What he thinks should be done next. And discussion. 2.0: Access to groups from a single service (GroupStore) Groups Manager for browse/edit and servant mode Authorization API with fixed logic for determining rights. PermissionsManager for browse/edit and servant mode Requirements for 2.1: Multiple sources of groups. LDAP access Easy customization of group service (hard to subclass; could not replace tiny parts of the service, had to replace the whole thing). Locking and caching in multi-server environment. Override default authorization logic. Released in 2.1: Composite group service design supports multiple components Component service design assembled from configurable parts LDAP group store -- as an example of how to write a group store. Locking and caching services for exclusive access and cache synchronization. Pluggable permission policy. Columbia's ideas for future (2.2 or whatever it's called) Bring LDAP group store to production level (right now Columbia has low hundreds of users, will go to few thousand over next six months, code needs to be more efficient) Better documentation of composite design for implementors (configuration tutorial?) Group Manager improvements (in progress) refactoring, and more ease of use as a servant. Code clean-up. Multiple sources of permissions (they want to actually implement an authorization service which itself can handle multiple sources.) Alex suggests in that case there ought to be some notion of prioritizing different sources as to which is more important in determining result. Lock and cache higher-level permission objects. Document authorization for implementors. Discussion Jim: a) Very important work, thanks for great job. B) Perhaps we need a doc to the basic concepts of role-based authorization. C) There is now XACML (a 'language' for authorization) Ken; UBC -- a system of roles with a flat list, no relationship between the roles. There were hundreds of roles. They reimplemented one method of AuthorizationImplementation in 2.0. (after asking Cornell how we did it). Ken: The permissions related to the groups manager should be a type of its own. Alex: There will be a GroupsManagerPermissionsPolicy that you can replace. Ken: Is there a rewrite of the PermissionsManager (PM) channel? Alex: we never intended it be used as a channel; but as a servant. (e.g. from the Channel Admin) Ken: how will we assign permissions in Aggregate Layouts? I guess we could get by without a redesign but it would be better to have an improved UI for permissions management. Alex: Let's put PM improvement on future list (it's on Columbia's) but I can't commit to working on it until late 2004. Ken: Alex uses PM servant on their Announcements channel. Do users grasp it? Alex: We don't get complaints. Dan: If you replace the pluggable permission policy, the meaning of what the PM is showing may not match what the alternate algorithm is actually doing. Nick: They have their own groups design. The Group object in uPortal doesn't have a way to Type itself. Alex: What you want is metadata about a group. Try the EntityPropertyRegistry. There is a single writable store. You can have any number of read-only sources as well. And the various sources have priorities (which takes precedence?). there's a DTD for the XML configuration file. (EntityPropertyRegistry.xml in the properties directory). Caching/Locking et alia [Dan Ellentuck]Ostensibly about caching/locking, but also about enterprise services for the portal and, what is an entity? And how to run in a multi-server environment. In.2.1 had a requirement from groups system. Ability to lock and cache groups. Outline: Rationale Concurrency packages ? ? Rationale for locking and caching Grew out of requirement to update and cache in multi-server environment Alternative open source packages (looked at, such as JCache) UPortal attitude towards enterprise services. Approach: develop a sufficiently flexible API and a simple implementation so it could be replaced by an open source or commercial solution. A year or so ago sites seemed not to be ready to deal with enterprise level design of uPortal. But we have to fill in with sort of "enterprisey" things. Do we have a specific attitude or policy toward enterprise services? In lieu of enterprise services, do this: Minimal service api's Disposable implementations IBasicEntity and EntityIdentifier [has key and type] Entity types [store of known types] Service Facades Concurrency Packages An entity identifier is like a Key. For these locking and caching things, they work on IBasicEntities. Dan showed the locking and caching APIs from 2.1. The package org.jasig.portal.concurrency has the interfaces and exception classes. concurrency.locking and concurrency.caching have the actual implementations. Caching -- add, remove, and update. Locking -- get a lock, or get for a particular duration, release or renew a lock. Can convert a lock from one type to another (so far, shared or exclusive read and write locks). Dan talked through the service configuration items in portal.properties org.jasig.portal.concurrency.multiServer et cetera. Future uses: IAuthorizationPrincipal ChannelDefinition ? Discussion: Ken: What if we wanted to use this on ChannelDefinition, what would we have to change? Dan: It would have to implement IBasicEntity. The code that updates the definition would have to get a lock, and deal with the situation if it can't get the lock. Once change is done, release the lock and update the entry in the cache. Alex: We are concerned with how long it takes to log in. Channel definitions are not cached, so they all have to be read for every user. We could save 5 seconds for every login. Dan: These (locking and caching) are actually done through façades in the services package. Ken: Caching channel definitions is something that should be done immediately -- it's like a bug fix. Alex: IPerson is now an IBasicEntity Ken: Should anything we're persisting become an IBasicEntity? Dan: The question is, what's the danger of unrestricted (unlocked) access? And then, how difficult would it be to implement this? Might be tough for, for example, layouts. And how important is it to synchronize caches? For some things the info is not timely and doesn't matter. Ken: What is our attitude about enterprise? Make it possible to have lightweight services provided. Jan: We tried to use some EJB app servers, but there was a significant performance hit, and it needs a lot of extra code (programming overhead). Transactions against an RDB? It's good for that, but if you don't need such, leaving it out gets rid of a large implementation/performance burden. Separate the question of transactional semantics from synchronization issues. Dan: Wanted to delete users. Could not find a way to absolutely guarantee the database update would all succeed. Because one part of it can fail. What do you do regarding already deleted parts? Jan: Report such a failure as well as possible. Peter: We should avoid using transactions at least in the framework, and the coding required is so complicated. If it's absolutely needed by the community, we could bring in some JTA implementation. [break] WSRP vs. Remote Channels [Ken Weiner]In 2.1 we have the Remote channel type, tries to do the same thing as WSRP. We want to transition to WSRP if and when it becomes important. You can actually download examples of WSRP from IBM's Web Services Tool Kit. Ken can't google anything else that's actually compatible. The Web Services API requires having certain structures that you transmit. But they don't provide any code for the structures. The only implementation of those he could find does use Oasis's class names, but it is only in jars (no source) in IBM's toolkit. Ken: we will build a client to work with WSRP, a new channel type, and make it work with IBM's examples. After that's released, look at offering channels through it. Jim: Vignette and Plumtree both have WSRP channels out for about 3 or 4 months. IBM wants Apache to write the code. (Jim asked the question:) Cornell's National Science Digital Library (NSDL) offers the NSDL service as a uPortal. When should they try offering a remote channel or WSRP? Ken: They should try it as soon as they have the resources to try it. If a service is offered that a number of different locations would want to use, offer it as WSRP. Ken: If you study the WSRP standard, there's this portal effort that is trying to do the same things uPortal already did. For example their CSS classes. In JSR 168 considers channels to have "modes" e.g. help mode, edit mode, also "states" (minimized, maximized). Maybe in uPortal 3.0 adapt to those new standards? There are now new companies with ads "we specialize in making portlets". Jim: Someone should look at the various competing standards relevant to uPortal comparatively and decide which ones 'win'. Ken: The new standard that's going to mess us up first is the skin standard (the CSS thing). WSRP clients won't be able to render our channels. Jim: The JA-Sig board needs to address this standards issue at their next meeting. An aside, you can't duplicate the eduPerson document -- which is an open standard. His opinion on JSR 168 -- too early to do anything about it yet. Ken: I will try to write a channel adapter to Jetspeed's API, which is essentially what JSR 168 is. Has anybody tried to use the remote channel? Ken says he's heard a few people who tried it. Someone said "I think people are holding back because it's eventually going to be replaced." CAR Files [Mark Boyd]He made a handout of a diagram that shows what's there. A CAR file is a way to bundle a channel into a jar. Only two places the code needed to be changed, were in the ChannelManager and in the ChannelStaticData. ChannelManager calls "CarClassLoader" class which delegates to "CarResources" (a singleton) that loads from the 'car'. You can load a class, or a resource. A "CarResourceWorker" can load for example an image. ChannelStaticData has a new method GetMediaBase (per channel) that determines where the data is coming from. The main limitation -- supports GIF, JPG, and JPEG only. He had to hard-code the mapping of extension to Mime type. Needs to write code to use those mappings from the web.xml. Also, need to add a 'deployment descriptor' to a channel that would define other Mime types. The uPortal as currently designed has two notions of channels. Some to subscribe to, and others which are there sort of as part of the framework (header, channel manager, etc.). SCT's Campus Pipeline toying with idea of modifying layout startup code, which checks which infrastructure channels the given user has permission to use, and adds them in; and strips them out when the user saves. The "deployment descriptor" mentioned above would document that sort of stuff, who has permission to use it and so on. What should that descriptor be called and where should it be located? What if the channel needs a new table and initial contents? That could be put in the deployment descriptor as well. The one problem is whether the channel categories you anticipated, and/or the groups you expect, are actually on the destination portal site. What if the installing site lacks the category or group? Ken: A remote channel is not in anybody's layout. The server has to have a similar concept like what SCT said re infrastructure channels. There are two kinds of deployment descriptor, one for actual java classes, and one for some other kinds of channels that don't require any java, like a GenericXSLT channel. Ken wrote a little tool that checks that either the group or the category actually exists; if not it maps them to something else. A car file might have only one channel, or maybe a related bunch of channels. For example it could have some java classes that essentially make a new channel type, then you could provide some instances that are of the new type. Alex: Is skeptical about automating the categories and groups creation for a CAR channel (in those instances where the specific group and category names do not exist). Instead, make it possible to install a channel without groups or categories, and then go into the editor to add those. Peter: Some channels are published only once, others are 'types'. For channels that don't actually cause a channel type to appear. They have descriptors and parameters as well. Presumably a custom channel would not need a descriptor? Or do we make a descriptor required for every new channel? Mark: There's a precedent. Every webapp requires a web.xml file, so it's sensible to require a deployment descriptor for any batch loaded (as opposed to hand-entered) channel. Ken: To fix a bug, in 2.1.1 the channel publisher won't permit publishing a channel without groups or categories. Mark: This makes it impossible to add another infrastructure channel which wouldn't be in any groups. Ken: Let's determine some examples of situations where we would use a CAR file, and outline the steps that would be needed to import it. Mark: What if there are some things that the recipient installer would want to specify at import time? [comments from others, then] so the descriptor would have only the immutable portions of the channel characteristics. Steve V: There may be some things needed that are outside the CAR file. Mark: We had not considered that yet. Peter: what is the workflow for using a CAR? Download the CAR into the CAR directory. Register the CAR. Create new channel type [if needed] Publish the channels in the CAR. The discussion went off into designing the workflow. Mark wants creation of new channel types to be just as automatic as creating a plain channel. Alex: Let there be another item on the Channel Admin: "Install a CAR file." Mark went through a scenario that explained how the CAR is used. Alex: To fix the problem with group not already existing, just build a new group into the framework "Installed Channels" and always put a CAR'd channel into that initially. Peter did not think that there should be such a great difference between a regular channel, and a channel type. The discussion of this lasted quite a while. [lunch] A CAR installation can do one or all of these three things: Creating database tables. Registering zero or more CPD's (doesn't necessarily become a channel type) Fully publishing zero or more channels (to do this it would read a new kind of XML file outside the CAR, which would define everything, and optionally groups and categories. If the latter not present, it would put them in a special group and/or category) Channel CVS Repository [Ken Weiner]Nobody wants to own this repository. We have a few things in there but people are not making "releases". Like the bookmarks for example, it's just in there and you download whatever the current source happens to be and build it. Jan: "Nobody wants to take the responsibility of saying 'this binary works'." Someone said that Jim should bring this up to the JA-Sig board. ____________ Howard Gilbert: When I install in a new environment, I never quite get everything right, and I get these exceptions which are never useful. It doesn't say what the problem really is. The exceptions are almost always thrown by a static initializer. What he wants to get is a message "This file is missing" or "This property is missing." Not "class initialization failure". Secondly, try deleting your property file to test your new code to make sure that it can handle missing properties, at least to the degree of saying what is missing. Ken: Forgot to ask -- should we specify the character encoding for XSLT files? UTF-8? Shoji Kajita said blank should be okay; if there is any Japanese in the file, UTF-8 is the default. Nevertheless, the consensus was that there would be an effort to specify UTF-8 in all stylesheets. THE NEW FEATURES LIST [Ken Weiner]Discussion, some people proposing features: Alex: The publication servant. (he wants this for Content Management System anyhow, so he can do the publishing from inside the CMS instead of jumping out to the portal channel admin channel.) A scheduling service. Some event happens at a particular time. Sort of like cron jobs. Peter: Some of the things in the services package are used in the framework, some of them support channels. Some of them are instantiated. Should we put the services in JNDI? Among other reasons, we could get them to start when the portal starts, and we could put permission stuff on them. Ken: Speaking of JNDI, we now haphazardly happen to have two different JNDI instances, the Tyrex one and the container one (the latter you get if you don't specify). Re the memo from Steve Barrett about handling secure channels: a guy from SCT said that they had already done it very much the same way. When you specify such a parameter on such a channel, when the theme transformation comes in, they strip off the URL and parm and pass it to the theme stylesheet, and check whether it has this parm. If the channel is focussed and secure, they do a redirect to an https. (e.g. they have an 'account manager' link on the home page, if you click it it brings up such a focussed channel). And if it's not focussed, the framework shows an error message. SCT did not seriously consider a proposal like Susan Bramhall's (on a page with both SSL and non-SSL channels, proxy the non-SSL content through the uPortal server). Ken favored Susan's proposal because it's an inconvenience to the user to have to focus it after getting that error message. Another suggestion that SCT had was to require a tab to be SSL (but they didn't actually implement that). The other way is what Susan Bramhall and Howard Gilbert at Yale are doing: proxy all the non-SSL content. A last resort way to deal with this is to force the IE 5.x people to upgrade to 6. (What about Apple's Safari browser? Yale hadn't checked yet). Opera and Mozilla won't complain, Netscape 7, 4 and IE 6 you can disable the message. Ken asked should we add the parm (since we are going to change the database again next time anyway, we might as well). Peter pointed out maybe some pages of a channel are secure and others are not, so it would be dynamic. Ken now would like to have both ways, the SCT/Cornell way, and the Susan/Howard mixed-content way. Howard: thinks this issue is "a tradeoff between user convenience and cycles, and in today's market, cycles lose." Cycles are cheap. Jan said that for small schools cycles are really important. Peter: Let's say that a channel can dynamically make itself "more secure" but not "less secure." And let's say once we go to SSL, stay there. Peter: Nor are we to be presenting insecure content as secured. So the SCT/Cornell way is cleaner in that sense. Ken: start with the SCT/Cornell way because it's already been demonstrated by SCT to work. To begin with we will leave out ability to more-secure it at runtime. SCT will do it. Peter told them it should not happen in the theme stylesheet, because then everybody has to rewrite their themes. Should happen in the Java filter. SCT agreed, Peter will email them where in the code to do it. Ken: "The next dot release should be six months from now." It always seems like too much time but then we're always rushing. Jan: Two "defects." Add a factory mechanism to the CAR class loader so an alternate implementation can be dropped in. Add a factory mechanism for the channel renderer. The current implementation of the channel renderer has a couple of problems with respect to SCT's environment. [Alex: All of the channels that Columbia writes, they have an XML document that is passed in to the channel that allows saving of state and other things. A "channel session model" document. They will put all of their strings in there.] -------------------- Ken went and privately scanned the new features list. The reason was there were too many people present to be able to get through discussing all the features line by line. He will email it to everybody for comments and corrections. This was about 2:30 PM that we 'broke'. Then at 4:40 or so after about 2/3 of the people had gone, it was suggested that he go through them. |