Google SoC Idea: web-interface library

Joris Guisson joris.guisson at gmail.com
Mon Mar 24 08:58:01 GMT 2008


Seems like an interesting idea, we at ktorrent would be willing to try this
out, I'm not really satisfied with the current HTTP server implementation in
ktorrent.

Joris,

On Sat, Mar 22, 2008 at 3:19 PM, Matej Svejda <mata at aw-modell.at> wrote:

> > Why create a new server? There are plenty of web servers around.
> Well, I think that creating a really small server myself would be easier
> than
> trying to integrate Kross into an existing server (but I might be
> wrong...).
>
> > >   * connect this web server to use Kross for executing scripts. This
> > > would give it instant ability to write code in Python, Ruby,
> > > JavaSciprt (?) and Java
> > What would be the usage scenario for this kind of language connection?
> How
> > would somebody wanting to provide a web interface for his KDE
> application
> > make use if it?
> Developing web-apps in scripting-languages like Ruby or Python seems like
> the "natural" thing to do (that's how most of the current web-interfaces
> work). But the problem here is how to communicate between C++-software and
> those languages.
> This is where the whole integrating-Kross-into-the-server-idea kicks in:
> Accessing C++-objects in those scripting languages would become as easy as
> it
> is now when you write scripts for Kross-applications. You would just need
> to
> call something like...
>        serverInstance->addObject(object, "ObjectName");
> or ...
>        Kross::Action* action = new Kross::Action(this, "WebInterface");
>        action->setFile("script.py");
>        action->addObject(object, "ObjectName");
>        serverInstance->setAction(action);
>        serverInstance->trigger();
>
> Then you could do anything you like with that object in your web-interface
> script.
>
> > What would adding objects and module actually mean?
> Adding them to the script so they can be accessed as if they were "native"
> objects in the scripting language that is being used.
>
> > I understand the idea as a way to provide a way for existing KDE
> > applications to get a web interface, not the other way around, coupling
> > existing web applications to KDE. So in what way would PHP be relevant
> > here?
> It would give the programs the ability to use frameworks such as CakePHP
> or
> Prado. But that's not really required.
>
> > It depends on the concrete goal of the project and how it's approached.
> As
> > a generic solution it sounds like a pretty tough project to do in the
> > time-frame of the SoC. This of course also highly depends on your
> > background and how much you would have to learn to be able to become
> > productive.
> Well, I have moderate C++ skills but I have lots of experience with
> web-development. I think having a proof-of-concept implementation and a
> port
> of one of the existing interface to this library by the end of the summer
> (without the PHP-backend for Kross) should be doable. But again, I could
> be
> wrong...
>
> Matej
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080324/afacaf5b/attachment.htm>


More information about the kde-core-devel mailing list