280 likes | 464 Views
Special-purpose application servers Gregor J. Rothfuss Technical Director PostNuke O’Reilly Open Source Convention July 22-26, 2002. TOC. Whats wrong with app servers? The product The community The architecture The uses The future Q & A. Whats wrong with app servers?.
E N D
Special-purpose application serversGregor J. RothfussTechnical DirectorPostNukeO’Reilly Open Source ConventionJuly 22-26, 2002
TOC • Whats wrong with app servers? • The product • The community • The architecture • The uses • The future • Q & A
Whats wrong with app servers? • Supposition: Most programmers suck • App servers mainly support „good“ programmers • App servers are too generic, too high level
Special purpose app servers • Tenet: Provide cool stuff out of the box • Libraries alone dont woo anyone • Provide approaches on several levels • customization (Administration) • skinning (Layout) • addon development • Examples of this breed: • Midgard, PhpGroupware, PostNuke
Dedication: Greg Allan • Greg Allan a.k.a. Adam_Baum, the lead core developer and one of the four founding members of the PostNuke Development Project passed away from injuries sustained in a motorcycle accident. The accident occurred June 16, 2002 near his home in Meaford, Ontario in Canada.
Product: Some stats • 500,000 downloads to date • 20,000 sites running • 120+ modules available • 100+ themes available • PostNuke is IBM Server proven
Product: Target audiences • Private persons • Communities • Small businesses • Needs to • be easy to install, admin • have a good support infrastructure • run anywhere
Product: Why PHP? • Runs on most ISPs • Is easy to learn • Large amounts of legacy code • Cross platform: PN runs on Linux, Windows, OS 390, Solaris • Lean & mean
Product: Core Features • User management • Permissions • Templating • Modularity
The PostNuke community • 200+ developers • 20 international support sites • 14,000 registered users • Bottom line: PostNuke is about building and growing communities
Architecture: Goals • provide compatibility for modules • encourage code reuse • provide a secure environment • keep it as easy as possible (but no easier)
Architecture: Flow pnInit pnInit Sess Lang DB Site Sess DB Module(s) XML-RPC specific API Templates Theming Web (XHTML) RPC (XML)
Architecture: Components Themes / Templating Modules Blocks Utility Modules PN API ADODB DB: MySQL, Postgres, MSSQL, Sybase, Oracle
Architecture: Module Design • Separation of User and Admin Functions • Separation of Display and Operational Functions • Single Directory Installation • External Access to Module Functions
Architecture: Hooks • Modules can register hooks that will be called on specific events: • Item creation • Item display • Modules dont know who if anyone will implement their hook • Examples • Admin notification on user signup
Architecture : Cron • Modules can schedule events to occur on a regular basis • Examples: • Notification mails • Cleanup tasks • Syndication
Architecture : Permissions • ACL based on regular expressions • Supports unlimited groups • Supports nested groups • Can be a challenge to understand • Simpler admin interfaces in development
Architecture : Syndication • Exchange site headlines with other sites • Based on RSS 0.91 • Format supported by hundreds of sites: • Reuters
Architecture : ADODB • Based on MS ADODB API principles • Strive for SQL 92 compatibility • Remaining quirks: JOIN, Auto-increase fields • CREATE TABLE is hard..
Usage Scenarios Community WebsitesForums, News, Syndication Small BusinessesShopping solutions, CMS Vertical Solutions pnCommunitypnEducation
The Future • support more databases • make module writing easier • develop more vertical solutions • port PostNuke to Midgard • increased scalability • rich applications