Hi. Pankaj Kumar Sharma <sharmapankaj1...@gmail.com> writes:
> For the record, I am a GSoC aspirant interested in project PTS rewrite in > Django [ > https://wiki.debian.org/SummerOfCode2013/Projects#PTS_rewrite_in_Django] > > Looking forward to get some ideas! > In addition to elements already added by the previous responses, let me add a few items : The PTS should continue provide Web interfaces for publishing different contents depending on the client connecting through content-negociation. Currently, it provides (static) documents either as HTML, for regular browsing by humans, or (static too) RDF meta-data for machine consumption [0] (all generated by XSLT stylesheets). I'm not sure Django integrates much REST support and content negociation, but I guess the publication of pages should obey a kind of MVC, with potentially many different Views for a single object. So for instance, a Source Package should be rendered either as (X)HTML or, through content-negociation [1], as Turtle, or RDF+XML, or whatever other formats are interesting for interoperability reasons (JSON for inclusion in other portals or Web 3 apps, etc.) I guess HTML is of course a priority (hence Web templates alread mentioned), but other formats may require more structured "serialisation", maybe quite close to the underlying Model of the Python objects handled by the core of the PTS. I imagine that only the content-negociation evaluation algorithm (checking contents of the provided Accept HTTP header) would really be dynamic, the rest could just be publishing pre-rendered static pages. Note that Apache already does this ConNeg currently, and there may not be much need for delegating this to Django AFAICT. I imagine that some dynamicity could be helpful in the case of different contents published whether the connection is authentified or not, for instance to reveal security issues details to maintainers only, or people's addresses, or other sensitive informations... but I'm not so sure this is so much a requirement... I hope this makes sense. Also, should this be of any help, the ADMS.SW ontology which I used to implement the RDF output by the PTS [2] proposes an OO model for describing links between packages and their releases, which could be reused for inspiration in implementing the Model part / Python classes for the Django rewrite. Don't hesitate to check [2] for more details (slightly outdated, but cUrl is your friend to go check the live version on the PTS ;-). Also, regarding dynamic vs static pages, is i18n of the Web pages a goal of the rewrite ? Maybe I've missed something, but I think I heard that there was a tentative rewrite of the Mentors.Debian.[net|org] site with Django... and it could also be interesting to investigate in more details the potential cooperation/reuse, for instance in terms of Auth mechanics relying on the Debian LDAP, or other sources, etc. It would be sad to see concurrent yet incompatible implementations in 2 Django apps ;-) I'm looking forward to see your progress, and maybe helping on this project, if possible. Best regards, [0] http://packages.qa.debian.org/common/RDF.html [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 [2] http://www-public.telecom-sudparis.eu/~berger_o/papier-swese2012/ -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip39k7xm....@inf-8657.int-evry.fr
