Log in
Forgot your password?
History for MarkupCompressionAndDecompression
??changed:- Markup Compression and Decompression * This is a more general form of the w3c standard for HTML compression applied to Zope's content. What I mean is that all tags should be recognized and handled by these routines within Zope, not just HTML tags. * Database to Edit Area: Structured whitespace is added to the text stream. Comments are optionally added to the stream. * Edit Area to Database: Whitespace is subtracted from the text stream. Comments are indexed separately with markers embedded into the stored text stream. * If the text stream is not being sent to an edit area then the comments and whitespace are omited, reducing the bandwidth required. * Scalability hopefully would not be comprimised as the ratio of clients editing content should be very small compared to the number of clients viewing content. At this time I don't understand Zope's architecture enough to know if this will be an issue. This idea WILL add extra processing to fundemental routines in Zope however (send and recieve content) so I must point it out here for a Zope God to look at =). * The intent is to allow editing jobs of any markup (HTML, DTML, etc.) to be assigned to random networked coders on-the-fly. Consistent indentation allows each coder to understand the previous editors markup. Night Angel - member since yesterday =) -------------------------- Hi Night Angel =) <-> Hi! =) Have a look at "this post":http://lists.zope.org/pipermail/zope-ptk/2000-February/000401.html from the PTK mailinglist. It discusses the tricks you can pull if we implement a <dtml-component> tag. See the following posts: - http://lists.zope.org/pipermail/zope-ptk/2000-February/000347.html - http://lists.zope.org/pipermail/zope-ptk/2000-February/000400.html (unfortunately the rendering of the first post has been mispresented by pipermail. Use View Source on that page to get Paul's full meaning.) --MartijnPieters