Re: Guidance required for GSoC project PTS rewrite in Django
Hi.
Pankaj Kumar Sharma <sharmapankaj1992@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)
Reply to: