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="[log in to unmask]" target="_blank">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.
>