Mailing List Archive

Extensible Catalyst Applications: How?!
Hi everyone.

For the last week and a half I've been trying to figure out how to make my Catalyst application extensible, to no avail.

SCENARIO:

1. I have written a Catalyst application called MyApp (The name is a trademark belonging to me so don't steal it).

2. I want people (and me too) to be able to create plugins that extend the functionality of MyApp.

3. I want to create a plugin for MyApp, called "MyPlugin". This plugin in itself is a (near-)complete Catalyst application. It has its own controllers, models, views, etc.

4. I want to "mount" this plugin to some path on MyApp, such that all requests for a path beginning with "/myplugin", for example, are to be routed to MyPlugin's controllers.

5. The context is, of course, to be shared between the two. MyPlugin is seamlessly integrated into MyApp, but any MyPlugin logic is not to be added to MyApp. For example, I do not need to change MyApp.pm to add some MyPlugin specific code, like $c->controller eq $c->controller('MyPlugin::ShootMe') for example.

6. MyPlugin is to be, well, pluggable. I can enable and disable it as/when I wish.

WHAT I'M DOING NOW:

1. I develop MyPlugin as an integral part of MyApp, making all it's controllers MyApp-controllers, and update myapp.conf appropriately (adding a realm perhaps and MyPlugin-related configurations).

2. I add MyPlugin logic to MyApp.pm and maybe other files.

3. I shoot myself in the head.

WHY THIS IS BAD:

1. It's not pluggable.

2. I have interfered with MyApp's code (including myapp.conf) - very bad for development. While one (MyPlugin) depends on the other (MyApp), they should be separate entities.

3. I have shot myself in the head, that can't be good.

So, my question is, what am I to do in order to make my app extensible, at least in the way described above? Do I definitely need to create an API for MyApp? (I will anyway, but is that necessary for the scenario above?).

And also, how can I overcome potential problems like MyPlugin requiring the presence of Catalyst plugins not loaded by MyApp.pm?

Any help heavenly appreciated,
Ido Perelmutter.




_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
On Tue, Jun 2, 2009 at 7:45 AM, Ido Perelmutter <ido50@yahoo.com> wrote:
>
> Hi everyone.
>
> For the last week and a half I've been trying to figure out how to make my Catalyst application extensible, to no avail.
>
> SCENARIO:
>
> 1. I have written a Catalyst application called MyApp (The name is a trademark belonging to me so don't steal it).
>
> 2. I want people (and me too) to be able to create plugins that extend the functionality of MyApp.
>
> 3. I want to create a plugin for MyApp, called "MyPlugin". This plugin in itself is a (near-)complete Catalyst application. It has its own controllers, models, views, etc.
>
> 4. I want to "mount" this plugin to some path on MyApp, such that all requests for a path beginning with "/myplugin", for example, are to be routed to MyPlugin's controllers.
>
> 5. The context is, of course, to be shared between the two. MyPlugin is seamlessly integrated into MyApp, but any MyPlugin logic is not to be added to MyApp. For example, I do not need to change MyApp.pm to add some MyPlugin specific code, like $c->controller eq $c->controller('MyPlugin::ShootMe') for example.
>
> 6. MyPlugin is to be, well, pluggable. I can enable and disable it as/when I wish.
>
> WHAT I'M DOING NOW:
>
> 1. I develop MyPlugin as an integral part of MyApp, making all it's controllers MyApp-controllers, and update myapp.conf appropriately (adding a realm perhaps and MyPlugin-related configurations).
>
> 2. I add MyPlugin logic to MyApp.pm and maybe other files.
>
> 3. I shoot myself in the head.
>
> WHY THIS IS BAD:
>
> 1. It's not pluggable.
>
> 2. I have interfered with MyApp's code (including myapp.conf) - very bad for development. While one (MyPlugin) depends on the other (MyApp), they should be separate entities.
>
> 3. I have shot myself in the head, that can't be good.
>
> So, my question is, what am I to do in order to make my app extensible, at least in the way described above? Do I definitely need to create an API for MyApp? (I will anyway, but is that necessary for the scenario above?).
>
> And also, how can I overcome potential problems like MyPlugin requiring the presence of Catalyst plugins not loaded by MyApp.pm?
>
> Any help heavenly appreciated,
> Ido Perelmutter.

Why not just develop separate apps and deploy them to specific paths
via whatever backend engine you're using?

--
Eden Cardim Need help with your Catalyst or DBIx::Class project?
Code Monkey http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://edenc.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
This is possible, but has some drawbacks:

1. Both apps are entirely separate. The parent-plugin connection is kinda lost. I can't handle the plugins from inside the parent app.

2. Operation is engine dependant, which is not that bad but means more headaches for the end-user.

3. Two catalyst apps means more memory usage, cpu usage, etc. Not good, especially for apps running on shared or VPS hosting.

4. While this may answer the "separate paths" scenario, my app is still not extensible and people will not write plugins for it.

Thanks,
Ido.

--- On Tue, 6/2/09, Eden Cardim <edencardim@gmail.com> wrote:

> From: Eden Cardim <edencardim@gmail.com>
> Subject: Re: [Catalyst-dev] Extensible Catalyst Applications: How?!
> To: ido50@yahoo.com, "Development of the elegant MVC web framework" <catalyst-dev@lists.scsys.co.uk>
> Date: Tuesday, June 2, 2009, 4:30 PM
> On Tue, Jun 2, 2009 at 7:45 AM, Ido
> Perelmutter <ido50@yahoo.com>
> wrote:
> >
> > Hi everyone.
> >
> > For the last week and a half I've been trying to
> figure out how to make my Catalyst application extensible,
> to no avail.
> >
> > SCENARIO:
> >
> > 1. I have written a Catalyst application called MyApp
> (The name is a trademark belonging to me so don't steal
> it).
> >
> > 2. I want people (and me too) to be able to create
> plugins that extend the functionality of MyApp.
> >
> > 3. I want to create a plugin for MyApp, called
> "MyPlugin". This plugin in itself is a (near-)complete
> Catalyst application. It has its own controllers, models,
> views, etc.
> >
> > 4. I want to "mount" this plugin to some path on
> MyApp, such that all requests for a path beginning with
> "/myplugin", for example, are to be routed to MyPlugin's
> controllers.
> >
> > 5. The context is, of course, to be shared between the
> two. MyPlugin is seamlessly integrated into MyApp, but any
> MyPlugin logic is not to be added to MyApp. For example, I
> do not need to change MyApp.pm to add some MyPlugin specific
> code, like $c->controller eq
> $c->controller('MyPlugin::ShootMe') for example.
> >
> > 6. MyPlugin is to be, well, pluggable. I can enable
> and disable it as/when I wish.
> >
> > WHAT I'M DOING NOW:
> >
> > 1. I develop MyPlugin as an integral part of MyApp,
> making all it's controllers MyApp-controllers, and update
> myapp.conf appropriately (adding a realm perhaps and
> MyPlugin-related configurations).
> >
> > 2. I add MyPlugin logic to MyApp.pm and maybe other
> files.
> >
> > 3. I shoot myself in the head.
> >
> > WHY THIS IS BAD:
> >
> > 1. It's not pluggable.
> >
> > 2. I have interfered with MyApp's code (including
> myapp.conf) - very bad for development. While one (MyPlugin)
> depends on the other (MyApp), they should be separate
> entities.
> >
> > 3. I have shot myself in the head, that can't be
> good.
> >
> > So, my question is, what am I to do in order to make
> my app extensible, at least in the way described above? Do I
> definitely need to create an API for MyApp? (I will anyway,
> but is that necessary for the scenario above?).
> >
> > And also, how can I overcome potential problems like
> MyPlugin requiring the presence of Catalyst plugins not
> loaded by MyApp.pm?
> >
> > Any help heavenly appreciated,
> > Ido Perelmutter.
>
> Why not just develop separate apps and deploy them to
> specific paths
> via whatever backend engine you're using?
>
> --
>    Eden Cardim   
>    Need help with your Catalyst or
> DBIx::Class project?
>   Code Monkey           
>         http://www.shadowcat.co.uk/catalyst/
> Shadowcat Systems Ltd.  Want a managed development or
> deployment platform?
> http://edenc.vox.com/         
>   http://www.shadowcat.co.uk/servers/
>




_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
Ido Perelmutter wrote on 6/2/09 5:45 AM:
> Hi everyone.
>
> For the last week and a half I've been trying to figure out how to make my
> Catalyst application extensible, to no avail.
>
> SCENARIO:
>
> 1. I have written a Catalyst application called MyApp (The name is a
> trademark belonging to me so don't steal it).
>
> 2. I want people (and me too) to be able to create plugins that extend the
> functionality of MyApp.
>
> 3. I want to create a plugin for MyApp, called "MyPlugin". This plugin in
> itself is a (near-)complete Catalyst application. It has its own controllers,
> models, views, etc.
>

Ido,

First, the word "plugin" is overloaded in this email, so it's difficult for me
to tell whether you mean plugin in the Catalyst::Plugin::* sense or in the more
general "drop-in feature extension" sense. I'm going to assume the latter, since
the former just makes No Sense to me at all.

Second, I too have tried various approaches to the idea of a base Catalyst app
that can be installed and easily extended by the user. The solution that I've
come up with (for now) is the style I use in CatalystX::CMS, where I have a base
Model, View, Controller and Action class, and some examples of how to use them
in your own application. The same goes for CatalystX::CRUD::YUI, which is a
full-featured CRUD app for use with DBIC or RDBO. I use
Catalyst::Plugin::Static::Simple::ByClass to serve static assets (css/js/img)
that are distributed with each package.

The approach I've settled on is a "some assembly required" pattern, with some
standard Helper classes to generate the basic .pm files. This isn't as turn-key
as some people like; otoh, it makes it much easier to extend and override the
basic functionality, since there's nothing magical about the base classes.

good luck,
pek

--
Peter Karman . http://peknet.com/ . peter@peknet.com

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
Interesting. Oddly I'm trying to find out how to do the same type of
thing in Rails right now, and in doing so I realized I didn't know how
to do it properly in Catalyst either.

The need seems to be pretty general as people move forward with
deploying applications rather than one-off web sites. You want a core
application that has various modules. You want to give this to someone
in a way that it works out of the box, but they can:
1. Add new modules (which includes new database tables)
2. Subclass existing modules (e.g. add new field to a form/database,
override the functionality of a particular method)
3. Reuse modules (e.g. deploy multiple, slightly different, polls
within a site)

The database issue is particularly problematic. Catalyst/DBI doesn't
provide good automatic migration tools. Rails does, but assumes it's
all one big application. In the model above, modules would want to
migrate their tables somewhat independently. Practically speaking
though, it's impossible to 100% solve that problem with anything
automatic.

The subclassing is particularly important to me because I want to keep
the core modules as pristine as possible. New versions of the
application should be modified in separate class files. This is
because we need to maintain multiple copies of the application
(different variations for different clients). We need to merge bug
fixes between the versions, but don't want to pick up application-
specific changes. Anything we can do to keep the changes in separate
files is going to make life significantly easier. The same issues
apply if you have a core application that people are using on remote
installations. You want to be able to send them updates without
stepping on their changes.

Any thoughts on how to structure this in Catalyst?

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
Kee Hinckley wrote on 6/2/09 12:25 PM:
> Interesting. Oddly I'm trying to find out how to do the same type of
> thing in Rails right now, and in doing so I realized I didn't know how
> to do it properly in Catalyst either.
>
> The need seems to be pretty general as people move forward with
> deploying applications rather than one-off web sites. You want a core
> application that has various modules. You want to give this to someone
> in a way that it works out of the box, but they can:
> 1. Add new modules (which includes new database tables)
> 2. Subclass existing modules (e.g. add new field to a form/database,
> override the functionality of a particular method)
> 3. Reuse modules (e.g. deploy multiple, slightly different, polls
> within a site)
>
> The database issue is particularly problematic. Catalyst/DBI doesn't
> provide good automatic migration tools. Rails does, but assumes it's all
> one big application. In the model above, modules would want to migrate
> their tables somewhat independently. Practically speaking though, it's
> impossible to 100% solve that problem with anything automatic.
>

DBIx::Class deploy() method seems to work well. I wish RDBO had it (/me already
has it on todo list).

> The subclassing is particularly important to me because I want to keep
> the core modules as pristine as possible. New versions of the
> application should be modified in separate class files. This is because
> we need to maintain multiple copies of the application (different
> variations for different clients). We need to merge bug fixes between
> the versions, but don't want to pick up application-specific changes.
> Anything we can do to keep the changes in separate files is going to
> make life significantly easier. The same issues apply if you have a core
> application that people are using on remote installations. You want to
> be able to send them updates without stepping on their changes.
>
> Any thoughts on how to structure this in Catalyst?

CatalystX::CRUD::YUI does all that. At my last job I had 6 different apps
running with it, 4 of them on one machine. cpan -i CatalystX::CRUD::YUI and an
app restart was all it took to update them all.

--
Peter Karman . http://peknet.com/ . peter@peknet.com

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
2009/6/3 Peter Karman <peter@peknet.com>

> Kee Hinckley wrote on 6/2/09 12:25 PM:
> > Interesting. Oddly I'm trying to find out how to do the same type of
> > thing in Rails right now, and in doing so I realized I didn't know how
> > to do it properly in Catalyst either.
> >
> > The need seems to be pretty general as people move forward with
> > deploying applications rather than one-off web sites. You want a core
> > application that has various modules. You want to give this to someone
> > in a way that it works out of the box, but they can:
> > 1. Add new modules (which includes new database tables)
> > 2. Subclass existing modules (e.g. add new field to a form/database,
> > override the functionality of a particular method)
> > 3. Reuse modules (e.g. deploy multiple, slightly different, polls
> > within a site)
> >
> > The database issue is particularly problematic. Catalyst/DBI doesn't
> > provide good automatic migration tools. Rails does, but assumes it's all
> > one big application. In the model above, modules would want to migrate
> > their tables somewhat independently. Practically speaking though, it's
> > impossible to 100% solve that problem with anything automatic.
> >
>
> DBIx::Class deploy() method seems to work well. I wish RDBO had it (/me
> already
> has it on todo list).
>
> > The subclassing is particularly important to me because I want to keep
> > the core modules as pristine as possible. New versions of the
> > application should be modified in separate class files. This is because
> > we need to maintain multiple copies of the application (different
> > variations for different clients). We need to merge bug fixes between
> > the versions, but don't want to pick up application-specific changes.
> > Anything we can do to keep the changes in separate files is going to
> > make life significantly easier. The same issues apply if you have a core
> > application that people are using on remote installations. You want to
> > be able to send them updates without stepping on their changes.
> >
> > Any thoughts on how to structure this in Catalyst?
>
> CatalystX::CRUD::YUI does all that. At my last job I had 6 different apps
> running with it, 4 of them on one machine. cpan -i CatalystX::CRUD::YUI and
> an
> app restart was all it took to update them all.
>
> --
> Peter Karman . http://peknet.com/ . peter@peknet.com
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

May be what is needed is something like CatalystX::Extensions:: name space
and a new dev module to load eg scripts/myapp_extensions.pl that checks that
the extension is installed, checks required plugins by the extension are
install (may be with a call like CatalystX::Extensions::Example::requires())
then creates models, views and controllers (which presumably inherit from
the extension's packages). I'm not sure how you might go about setting
database tables and templates maybe they have to be distributed.

If any one likes this idea I would consider trying to create such a beast.
Any help would be appreciated though.

Regards
Ivan Wills

--
email/jabber: ivan.wills@gmail.com
/
/ _ _
/ \ / | | | |
/ \/ \_| | |
Re: Extensible Catalyst Applications: How?! [ In reply to ]
Ivan Wills wrote:
> If any one likes this idea I would consider trying to create such a
> beast. Any help would be appreciated though.

I kind of like the idea, but I'd want all of the templated component
generation to happen through Catalyst::Helper, and this depends on some
of the GSOC sponsored refactoring completing.

I have ideas about where to go with this certainly, and if you'd like to
work on it, then please write up a slightly longer summary of what
you're thinking of that people can comment on?

Cheers
t0m


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
On Wed, Jun 3, 2009 at 11:24 AM, Tomas Doran <bobtfish@bobtfish.net> wrote:
> Ivan Wills wrote:
>>
>> If any one likes this idea I would consider trying to create such a beast.
>> Any help would be appreciated though.
>
> I kind of like the idea, but I'd want all of the templated component
> generation to happen through Catalyst::Helper, and this depends on some of
> the GSOC sponsored refactoring completing.
>
> I have ideas about where to go with this certainly, and if you'd like to
> work on it, then please write up a slightly longer summary of what you're
> thinking of that people can comment on?

My Catalyst::Example::InstantCRUD can be viewed as an early attempt at
doing this. It is now just a CRUD + browsing (with paging and sort)
but the previous version could generate authentication code for the
application, unfortunately now it is so obsolete that I removed it.

I am now also waiting for the new helper infrastructure - but perhaps
it could be made more user friendly as a wizard, web based or a Padre
plugin.

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Extensible Catalyst Applications: How?! [ In reply to ]
How am I supposed to be reading Ivan's message? All I see is this:

Message: 8
Date: Wed, 3 Jun 2009 11:37:04 +1000
From: Ivan Wills <ivan.wills@gmail.com>
Subject: Re: [Catalyst-dev] Extensible Catalyst Applications: How?!
To: Development of the elegant MVC web framework
<catalyst-dev@lists.scsys.co.uk>
Message-ID:
<5d857fbe0906021837u6c85d03dwbd1665ea8af940cf@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

MjAwOS82LzMgUGV0ZXIgS2FybWFuIDxwZXRlckBwZWtuZXQuY29tPgoKPiBLZWUgSGluY2tsZXkg
d3JvdGUgb24gNi8yLzA5IDEyOjI1IFBNOgo+ID4gSW50ZXJlc3RpbmcuIE9kZGx5IEknbSB0cnlp
bmcgdG8gZmluZCBvdXQgaG93IHRvIGRvIHRoZSBzYW1lIHR5cGUgb2YKPiA+IHRoaW5nIGluIFJh
aWxzIHJpZ2h0IG5vdywgYW5kIGluIGRvaW5nIHNvIEkgcmVhbGl6ZWQgSSBkaWRuJ3Qga25vdyBo
b3cKPiA+IHRvIGRvIGl0IHByb3Blcmx5IGluIENhdGFseXN0IGVpdGhlci4KPiA+Cj4gPiBUaGUg
bmVlZCBzZWVtcyB0byBiZSBwcmV0dHkgZ2VuZXJhbCBhcyBwZW9wbGUgbW92ZSBmb3J3YXJkIHdp
dGgKPiA+IGRlcGxveWluZyBhcHBsaWNhdGlvbnMgcmF0aGVyIHRoYW4gb25lLW9mZiB3ZWIgc2l0
ZXMuIFlvdSB3YW50IGEgY29yZQo+ID4gYXBwbGljYXRpb24gdGhhdCBoYXMgdmFyaW91cyBtb2R1
bGVzLiBZb3Ugd2FudCB0byBnaXZlIHRoaXMgdG8gc29tZW9uZQo+ID4gaW4gYSB3YXkgdGhhdCBp
dCB3b3JrcyBvdXQgb2YgdGhlIGJveCwgYnV0IHRoZXkgY2FuOgo+ID4gICAgIDEuIEFkZCBuZXcg
bW9kdWxlcyAod2hpY2ggaW5jbHVkZXMgbmV3IGRhdGFiYXNlIHRhYmxlcykKPiA+ICAgICAyLiBT
dWJjbGFzcyBleGlzdGluZyBtb2R1bGVzIChlLmcuIGFkZCBuZXcgZmllbGQgdG8gYSBmb3JtL2Rh
dGFiYXNlLAo+ID4gb3ZlcnJpZGUgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgYSBwYXJ0aWN1bGFyIG1l
dGhvZCkKPiA+ICAgICAzLiBSZXVzZSBtb2R1bGVzIChlLmcuIGRlcGxveSBtdWx0aXBsZSwgc2xp
Z2h0bHkgZGlmZmVyZW50LCBwb2xscwo+ID4gd2l0aGluIGEgc2l0ZSkKPiA+Cj4gPiBUaGUgZGF0
YWJhc2UgaXNzdWUgaXMgcGFydGljdWxhcmx5IHByb2JsZW1hdGljLiBDYXRhbHlzdC9EQkkgZG9l
c24ndAo+ID4gcHJvdmlkZSBnb29kIGF1dG9tYXRpYyBtaWdyYXRpb24gdG9vbHMuIFJhaWxzIGRv
ZXMsIGJ1dCBhc3N1bWVzIGl0J3MgYWxsCj4gPiBvbmUgYmlnIGFwcGxpY2F0aW9uLiBJbiB0aGUg
bW9kZWwgYWJvdmUsIG1vZHVsZXMgd291bGQgd2FudCB0byBtaWdyYXRlCj4gPiB0aGVpciB0YWJs
ZXMgc29tZXdoYXQgaW5kZXBlbmRlbnRseS4gUHJhY3RpY2FsbHkgc3BlYWtpbmcgdGhvdWdoLCBp
dCdzCj4gPiBpbXBvc3NpYmxlIHRvIDEwMCUgc29sdmUgdGhhdCBwcm9ibGVtIHdpdGggYW55dGhp
bmcgYXV0b21hdGljLgo+ID4KPgo+IERCSXg6OkNsYXNzIGRlcGxveSgpIG1ldGhvZCBzZWVtcyB0
byB3b3JrIHdlbGwuIEkgd2lzaCBSREJPIGhhZCBpdCAoL21lCj4gYWxyZWFkeQo+IGhhcyBpdCBv
biB0b2RvIGxpc3QpLgo+Cj4gPiBUaGUgc3ViY2xhc3NpbmcgaXMgcGFydGljdWxhcmx5IGltcG9y
dGFudCB0byBtZSBiZWNhdXNlIEkgd2FudCB0byBrZWVwCj4gPiB0aGUgY29yZSBtb2R1bGVzIGFz
IHByaXN0aW5lIGFzIHBvc3NpYmxlLiBOZXcgdmVyc2lvbnMgb2YgdGhlCj4gPiBhcHBsaWNhdGlv
biBzaG91bGQgYmUgbW9kaWZpZWQgaW4gc2VwYXJhdGUgY2xhc3MgZmlsZXMuIFRoaXMgaXMgYmVj
YXVzZQo+ID4gd2UgbmVlZCB0byBtYWludGFpbiBtdWx0aXBsZSBjb3BpZXMgb2YgdGhlIGFwcGxp
Y2F0aW9uIChkaWZmZXJlbnQKPiA+IHZhcmlhdGlvbnMgZm9yIGRpZmZlcmVudCBjbGllbnRzKS4g
V2UgbmVlZCB0byBtZXJnZSBidWcgZml4ZXMgYmV0d2Vlbgo+ID4gdGhlIHZlcnNpb25zLCBidXQg
ZG9uJ3Qgd2FudCB0byBwaWNrIHVwIGFwcGxpY2F0aW9uLXNwZWNpZmljIGNoYW5nZXMuCj4gPiBB
bnl0aGluZyB3ZSBjYW4gZG8gdG8ga2VlcCB0aGUgY2hhbmdlcyBpbiBzZXBhcmF0ZSBmaWxlcyBp
cyBnb2luZyB0bwo+ID4gbWFrZSBsaWZlIHNpZ25pZmljYW50bHkgZWFzaWVyLiBUaGUgc2FtZSBp
c3N1ZXMgYXBwbHkgaWYgeW91IGhhdmUgYSBjb3JlCj4gPiBhcHBsaWNhdGlvbiB0aGF0IHBlb3Bs
ZSBhcmUgdXNpbmcgb24gcmVtb3RlIGluc3RhbGxhdGlvbnMuIFlvdSB3YW50IHRvCj4gPiBiZSBh
YmxlIHRvIHNlbmQgdGhlbSB1cGRhdGVzIHdpdGhvdXQgc3RlcHBpbmcgb24gdGhlaXIgY2hhbmdl
cy4KPiA+Cj4gPiBBbnkgdGhvdWdodHMgb24gaG93IHRvIHN0cnVjdHVyZSB0aGlzIGluIENhdGFs
eXN0Pwo+Cj4gQ2F0YWx5c3RYOjpDUlVEOjpZVUkgZG9lcyBhbGwgdGhhdC4gQXQgbXkgbGFzdCBq
b2IgSSBoYWQgNiBkaWZmZXJlbnQgYXBwcwo+IHJ1bm5pbmcgd2l0aCBpdCwgNCBvZiB0aGVtIG9u
IG9uZSBtYWNoaW5lLiBjcGFuIC1pIENhdGFseXN0WDo6Q1JVRDo6WVVJIGFuZAo+IGFuCj4gYXBw
IHJlc3RhcnQgd2FzIGFsbCBpdCB0b29rIHRvIHVwZGF0ZSB0aGVtIGFsbC4KPgo+IC0tCj4gUGV0
ZXIgS2FybWFuICAuICBodHRwOi8vcGVrbmV0LmNvbS8gIC4gIHBldGVyQHBla25ldC5jb20KPgo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gQ2F0YWx5
c3QtZGV2IG1haWxpbmcgbGlzdAo+IENhdGFseXN0LWRldkBsaXN0cy5zY3N5cy5jby51awo+IGh0
dHA6Ly9saXN0cy5zY3N5cy5jby51ay9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vY2F0YWx5c3Qt
ZGV2Cj4KCk1heSBiZSB3aGF0IGlzIG5lZWRlZCBpcyBzb21ldGhpbmcgbGlrZSBDYXRhbHlzdFg6
OkV4dGVuc2lvbnM6OiBuYW1lIHNwYWNlCmFuZCBhIG5ldyBkZXYgbW9kdWxlIHRvIGxvYWQgZWcg
c2NyaXB0cy9teWFwcF9leHRlbnNpb25zLnBsIHRoYXQgY2hlY2tzIHRoYXQKdGhlIGV4dGVuc2lv
biBpcyBpbnN0YWxsZWQsIGNoZWNrcyByZXF1aXJlZCBwbHVnaW5zIGJ5IHRoZSBleHRlbnNpb24g
YXJlCmluc3RhbGwgKG1heSBiZSB3aXRoIGEgY2FsbCBsaWtlIENhdGFseXN0WDo6RXh0ZW5zaW9u
czo6RXhhbXBsZTo6cmVxdWlyZXMoKSkKdGhlbiBjcmVhdGVzIG1vZGVscywgdmlld3MgYW5kIGNv
bnRyb2xsZXJzICh3aGljaCBwcmVzdW1hYmx5IGluaGVyaXQgZnJvbQp0aGUgZXh0ZW5zaW9uJ3Mg
cGFja2FnZXMpLiBJJ20gbm90IHN1cmUgaG93IHlvdSBtaWdodCBnbyBhYm91dCBzZXR0aW5nCmRh
dGFiYXNlIHRhYmxlcyBhbmQgdGVtcGxhdGVzIG1heWJlIHRoZXkgaGF2ZSB0byBiZSBkaXN0cmli
dXRlZC4KCklmIGFueSBvbmUgbGlrZXMgdGhpcyBpZGVhIEkgd291bGQgY29uc2lkZXIgdHJ5aW5n
IHRvIGNyZWF0ZSBzdWNoIGEgYmVhc3QuCkFueSBoZWxwIHdvdWxkIGJlIGFwcHJlY2lhdGVkIHRo
b3VnaC4KClJlZ2FyZHMKSXZhbiBXaWxscwoKLS0gCmVtYWlsL2phYmJlcjogIGl2YW4ud2lsbHNA
Z21haWwuY29tCiAgLwogLyAgICAgICBfICAgXwovICBcICAvIHwgfCB8IHwKLyAgICBcLyAgXF98
IHwgfAotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KQW4gSFRNTCBhdHRh
Y2htZW50IHdhcyBzY3J1YmJlZC4uLgpVUkw6IGh0dHA6Ly9saXN0cy5zY3N5cy5jby51ay9waXBl
cm1haWwvY2F0YWx5c3QtZGV2L2F0dGFjaG1lbnRzLzIwMDkwNjAzLzViNDNhNGIxL2F0dGFjaG1l
bnQuaHRtCg==

------------

Thanks,
Ido Perelmutter.




_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Re: Re: Extensible Catalyst Applications: How?! [ In reply to ]
Ido Perelmutter wrote:
> How am I supposed to be reading Ivan's message? All I see is this:

Get a mail client which can deal with MIME and base 64 encoding (as
specified in RFC1421 in 1993).

Alternatively, google for 'base 64 decode' and paste the encoded body
chunk into a base 64 decoder and text will come out..

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev