While were slightly trailing in the Listserv version we use (hope to get a budget soon ;) im limited on commenting what the RSS features will actually accomplish. However Id think about whether you want to really spend (at this time) your limited bullets/favors with the techies in charge of this project by running after tracking the last message from a list. Most people generally have their mail client open all the time so if they get a mail from a list they'll know about it. This is a scenario where PUSH-to-client (mail) is more practical/ergonomic then a client-PULL (http) model... Instead have students/users be able to utilize the full functionality of Listservs panels (add/remove/digest/archives/etc.) within the centralized portal to begin with. Make sure you have simplified help/policy files accessible and your in play. The fastest way to do such an integration would be to simply stick Listservs web panel under a tab of the Oracle App by using IFRAME command and doing a login automatically from the LDAP. This can be configured/coded probably in under an hour with any web friendly scripting language such as php or perl. So when a user logs into the portal and clicks the Listserv tab he can automatically be logged into the Listserv panel shown within a oracle app generated page. I believe all that oracle would need to do is something like; <IFRAME SRC="http://user:[log in to unmask]" HEIGHT="500" WIDTH="700" FRAMEBORDER="0"></IFRAME> I think once students start using the Listserv app and it ends up being a decent % of the overall portal usage you can push for more resources. I think this approach will also allow your teachers (or whoever setups lists) to easily create new lists without needing to bug someone else too much. Easier usage/configs mean more people more lists, more lists more option, more options more usage, more usage more resources... ;) Paul had a valid comment on passwords being in the open available for sniffing. However EACH time a typical user logs in the passwords are in the clear by default as well!! In fact given the variance of the clients physical locations there is much higher a possibility of individual logins being sniffed over campus WAN. I would assume that the oracle app, listserv and other servers are on a subnet, same switch. So EVEN if oracle app sends passwords to listserv in the open it travels a much lower risk zone (LAN). In either case Id STRONGLY suggest to run it all on SSL to begin with. You can very easily have a tunnel of any sort between client (oracle app) and listserv box on any port and then use a port forwarder on the same box or just run Best of luck, Omer. > Omer, your approach intrigues me. In fact, I just discussed this idea > with the director of our web portal project to see what his reaction > would be. I told him what I have in mind and about Omer's suggestion. > What I have in mind for each portal user is, at a minimum, to have a > tab on each user's web page which will identify each list to which > the person is subscribed, and maybe the most recent message that was > sent to each list. At this stage, I am not sure how, but we might > even be able to utilize the new RSS feature that became available to > us in Listserv 14.3. Being able to manage subscriptions via our new > portal would be nice too, but I want to focus on making the list's > available via the portal first and alerting portal users when new > postings are sent to each of their lists. > > The director who manages our portal has authorized me to meet with > their lead software developer to see how quickly this kind of feature > can be implemented. I hope to have that meeting today or tomorrow. > > In case anyone is curious, each time the status of someone who > applies to study here becomes a student here, his or her LDAP > information is assigned a flag which allows that person to go to an > account creation web site to validate their information, set up a > password, and create such resources as a portal account, email > account, housing system account, etc. A similar process is applied > to those who apply for a job here and then get hired. The entry of > people into the university community (students, faculty, and staff) > all flows into a centralized LDAP database. What would be nice is if > Listserv could utilize that LDAP data to facilitate integration into > other online services here such as a trigger signing up students to > lists for their courses, and delete subscriptions as students drop > courses in real time and signing up faculty/staff to departmental > lists, and so on. Right now, a lot of this integration is done at > night via batch processes, but it is all headed toward a real time > paradigm over the next few years. This is why it would not be > possible or wise for me to propose offering a new service that > depends on batch processing. > > Thanks Omer and Eric for your feedback, and also to W Brown. >