Tasty 1.1

1 view
Skip to first unread message

anders pearson

unread,
Dec 11, 2006, 11:26:03 AM12/11/06
to turbo...@googlegroups.com
I just released a new version of Tasty, the Turbogears based REST
tagging engine. The main change in this release is just that it now
works with TG1.0 (previously, it was on 0.8.9).

http://microapps.sourceforge.net/tasty/

I strongly recommend following the installation instructions:

http://microapps.sourceforge.net/tasty/installation.html

Upgrading from a previous version should mostly involve pulling in the
new requirements, making sure your configs haven't changed, and using
the start-tasty.py script instead of the old tasty_start.py.

--
anders pearson : http://www.columbia.edu/~anders/
C C N M T L : http://www.ccnmtl.columbia.edu/
weblog : http://thraxil.org/

Florent Aide

unread,
Dec 11, 2006, 12:08:29 PM12/11/06
to turbo...@googlegroups.com, anders pearson
Hi,

I've got a nice traceback on this url (linked from the tasty page):

http://thraxil.org/

Adam Jones

unread,
Dec 11, 2006, 4:58:47 PM12/11/06
to TurboGears

anders pearson wrote:
> I just released a new version of Tasty, the Turbogears based REST
> tagging engine. The main change in this release is just that it now
> works with TG1.0 (previously, it was on 0.8.9).
>
> http://microapps.sourceforge.net/tasty/
>
> I strongly recommend following the installation instructions:
>
> http://microapps.sourceforge.net/tasty/installation.html
>
> Upgrading from a previous version should mostly involve pulling in the
> new requirements, making sure your configs haven't changed, and using
> the start-tasty.py script instead of the old tasty_start.py.

After spending some time looking at the idea for microapps I thought it
might be useful to wrap access to a microapp from within TurboGears
into local and "proxied" controller methods. This allows you to run a
local copy of a microapp in your controller and gather data through
direct method calls or access the data remotely ... again through
direct method calls, this time on the proxy class.

Anyways, I wrote up the basic idea here:
http://docs.turbogears.org/1.0/TurboGearsAndMicroApps

Tasty looks pretty cool, glad to see it get updated for 1.0

-Adam

> --kORqDWCi7qDJ0mEj
> Content-Type: application/pgp-signature
> X-Google-AttachSize: 190

anders pearson

unread,
Dec 11, 2006, 5:25:38 PM12/11/06
to turbo...@googlegroups.com
On 2006-12-11 21:58:47 -0000, Adam Jones wrote:
> After spending some time looking at the idea for microapps I thought it
> might be useful to wrap access to a microapp from within TurboGears
> into local and "proxied" controller methods. This allows you to run a
> local copy of a microapp in your controller and gather data through
> direct method calls or access the data remotely ... again through
> direct method calls, this time on the proxy class.
>
> Anyways, I wrote up the basic idea here:
> http://docs.turbogears.org/1.0/TurboGearsAndMicroApps

This is a really cool idea. Thanks for writing it up. The microapps
concept is still sort of coagulating and ideas for this kind of glue
are a big help.

On the implementation side of things, one idea that I had that I
haven't had time to code up a test of is to use wsgi_intercept[1] to
automatically bypass HTTP and make the calls to a microapp in-process
for situations where they microapp is running on the same server as
the main app and happens to also be written in python with a WSGI
capable framework.

That way, you could use your proxy idea and have a registry somewhere
else (per-app configured, or global to a machine, or whatever) where
you specify that certain URLs map to WSGI applications. Done right,
that lets you have your cake of nicely seperated microapps while
letting you eat it too by skipping the latency of HTTP calls. Then, if
you need to scale out by moving the microapp to another server, you
just remove the entry in the registry and it goes back to HTTP
requests.

My intention with the microapps stuff is to have it be a
cross-language idea, but IMO, WSGI gives Python a huge advantage as
the implementation language of choice.

1: http://darcs.idyll.org/~t/projects/wsgi_intercept/README.html

Christopher Arndt

unread,
Dec 12, 2006, 7:41:20 AM12/12/06
to turbo...@googlegroups.com
Adam Jones schrieb:

> After spending some time looking at the idea for microapps I thought it
> might be useful to wrap access to a microapp from within TurboGears
> into local and "proxied" controller methods. This allows you to run a
> local copy of a microapp in your controller and gather data through
> direct method calls or access the data remotely ... again through
> direct method calls, this time on the proxy class.
>
> Anyways, I wrote up the basic idea here:
> http://docs.turbogears.org/1.0/TurboGearsAndMicroApps

Nice writeup! After reading this, I realized that I did a similar thing to
integrate gravatars in my blog application, i.e. I wrote a special controller,
that encapsulates access to the gravatar.com URL interface.

So you see, this is not limited to Microapps using a REST interface, as long as
the remote service exposes an URL interface and delivers results over HTTP, the
basic mechanism is the same.

I didn't separate the controller into a local and a proxy service, rather I let
the local service act as a forwarder if the requested result is not in the
local storage/cache. You can check it out in the cblog/widgets/gravatar module
of my CBlog app:

http://chrisarndt.de/projects/cblog/download/CBlog-20061130.tar.bz2

As another step to ease the usage of remote services in TurboGears websites,
this module encapsulate the display of the result in a fitting widget, i.e. an
image tag for a gravatar or, for your quote example, a nicely styled
<blockquote> element. To use the remote service in you template, you then just
have to insert a simple function call, e.g.

${gravatar.display('f...@bar.com', size=40)}

I also plan to write something similar for different website thumbnail
services, like Alexa, websnapr.com, artviper.net, etc.

Chris

Reply all
Reply to author
Forward
0 new messages