[Building Sakai] Filtering Content served from CHS

[Matthew Buckett]

This is a discussion about: http://jira.sakaiproject.org/browse/KNL-629

On 10 December 2010 16:59, Aaron Zeckoski <aaronz at vt.edu> wrote:
> Let me just start over then. Here is the use case:
> ------
> I am a system admin (or tool writer) and I need to add a custom bit to
> the top of every page (like some CSS or JS). I can do this by
> modifying the portal code (which is not awesome but it is at least
> possible) but I don't want to have to
> rebuild the system just to add a JS or CSS include. For resources
> content however, it is impossible for me as a novice developer to
> adjust the head of the page. I can manage something fairly
> straightforward like a provider or a system config option but I can't
> deal with modifying and rebuilding the kernel/access project. I make a
> tweak to the system config (or something similar) and now some extra
> content is added to head of every page rendered in the system.
>
> -----

If this is a common issue it might be better to have a more structure
framework for including extra bits of HTML in content served from
/access, which doesn't leave the writer of the filter with lots of
work todo. I'm slightly cautious about this as I don't feel I fully
understand the problem yet.


> And here is the problem we have seen come up:
> -----
> The resource content is rendered as invalid markup and/or not in the
> style of the rest of the system and/or outside the portal. Most users
> don't think of resource content as being outside the system/portal
> (even though the way it is rendered, it is).
> -----
>
> It seems like something that wraps the resource content could fix
> these issues, though it would need to be controllable by the system
> admin without a rebuild of the kernel (which is something we should
> strive to avoid anyway).
>
> I hope this restatement of the goal and problem are more clear.

The solution I implemented was never designed to support easily adding
filters for deployers, but by all means create a JIRA. I think we
could expose a registration API but this needs careful thought about
with respect to:

- How ordering is handled. If multiple filters are registered which
one gets the first stab at filtering it.
- Breaking existing functionality. If filters can prevent other
filters from running might they break existing functionality.
- Performance implications. Filters need to be very careful they don't
read the whole file into memory as content served from CHS may be GBs
in size. Filters should also be fast as they will be run every time
the content is downloaded.

-- 
  Matthew Buckett
  VLE Developer, LTG, Oxford University Computing Services