When designing such interfaces, please consider that the PyPI information is mostly static. If there's information missing, it should be easy to add it to e.g. a new info file placed into the package's "simple" directory that package tools could pick up in REST style.
Static directories just scale a lot better than any kind of (true) RPC interface and offloading some work to the client is certainly a good strategy as well. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 14 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2010-07-19: EuroPython 2010, Birmingham, UK 34 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ Alexis Métaireau wrote: > Hi all, > > Distutils2 will bring two APIs to request PyPI, via the "simple" API and via > the XML-RPC one. > > The fact is that the Simple API (it's just HTML pages, in a REST style as > pointed out by Mark) > does not provides all information we need, especially about distribution > dependencies or if we want to query some others things contained in the > metadatas. > > I'm working on two simple APIs for that, and I'll probably make a wrapper > around both, wich could choose the right one to use, depending on the needs > (eg. don't always rely on RPC or on "REST"). > > As we are talking about refactoring PyPI, it will probably be nice to have a > real REST API, that talks JSON or XML, replacing the HTML pages actually > served on http://pypi.python.org/simple/ :) > > Cheers, > Alexis > > On Mon, Jun 14, 2010 at 1:50 PM, Mark Ramm <m...@geek.net> wrote: > >>> If, in the future, package tools start to rely on RPC for >>> fetching data, the situation will shift towards needing full >>> functional mirrors again. >> >> Ideally we move some of this to be accessible via a more REST style >> interface where http GET requests (which would be by far the most >> common case) are still cacheable via all the standard mechanisms. >> >> I'm not a REST evangelist in most cases, but when scale and >> availability really do matter, REST buys you quite a bit by allowing >> you to scale and cache in all the ways that the web does. >> >> --Mark Ramm >> _______________________________________________ >> Catalog-SIG mailing list >> Catalog-SIG@python.org >> http://mail.python.org/mailman/listinfo/catalog-sig >> > > > _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
