Re: Beagle Web Interface coming ...

[Ikke <eikke eikke com>]

On Sat, 2005-02-05 at 22:53 -0700, Vijay KN wrote:
> Ikke,
> 
> An "integral http server" makes Beagle offer web access, independent of
> XSP.
I don't see what the pro's are of having a webserver inside beagle,
compared to using XSP.
> It makes webaccess a stand-alone feature in Beagle.
Why must it be standalone?
> Also, since it is part of Beagle, the DBus IPC overhead needed in case of a webapp
> hosted on an xsp is eliminated.
Guess I didn't think long enough here.
We don't need DBUS calls at all here. Because beagle is written in .Net,
we can just use the assemblies and exported functions directly, although
I thought Beagle was designed to communicate with it's frontends using
DBUS.
If you're concerned about DBUS overhead: the webapp won't produce more
overhead than BEST does. So maybe we should just put BEST into Beagled
itself too now?
> Beagle already has HTML generation code (for Best) as part of the Tiles assembly, 
> which I am reusing to support Web access.
That's not a point I think: export the Tiles used in Best as ASP.Net
webcontrols, and use these controls out of the Beagle assembly in your
webapp. Same result.
> 
> Since the ASP.Net engine (HttpRuntime) is a separate process, all we
> need to do is receive http requests, feed them to the ASP.Net engine
> pipeline and send back the response. I discussed this with Gonzalo
> (author for xsp) and he felt we could do this within a few hundred lines
> of code.
I know one can do this, I rewrote the MS Cassini webserver (similar to
XSP) while I was on Windows, bridging it to Apache so Apache could
server ASP.Net pages without using IIS, or starting a new "CGI" handler
on every request.
> So, we don't need a full fledged web server added in beagle to
> offer web access.
Not one of the same size like Apache or so, true. But I still don't get
why this should be a Beagle project, why can't we just use the webapp in
XSP?

> Another keypoint is that this minimal httpServer serves as the
> foundation for supporting the web service interface to Beagle. (If I
> replace beagled.aspx with beagled.asmx in
> http://localhost:8888/beagled.aspx, I get access to the web service
> interface to the local beagled). This will allow Beagle to be networked
> allowing access from other users, devices (PDA's) etc. So, it provide
> infrastructure to host both a 'web interface' and a 'web-service
> interface' opening new networking opportunities in future for Beagle.
I know one can write ASP.Net webservices like this too, but this still
doesn't show me the need of a (simple) webserver within Beagle. What you
say here can easily be done inside XSP, once more.
> 
> Vijay

I'm not trying to break down your work or something, not at all (I'm not
even a beagle dev), a webinterface would be a really cool thing. *But*
I'm worried a bit about the implementation details. We all know Beagle
currently has some memory problems (maybe not beagle-related, but
mono-related). Adding a webserver (which is quite a big object in terms
of memory-footprint) which is in-memory all time (duh, it's a
daemon/service) will only make the memory footprint of beagle even
bigger.
If this gets inside Beagle, I think it should be at least possible to
disable it on compile and/or runtime ('cause I can imagine a lot of
users dont really need this functionality, and are concerned about
memory footprint of the beagled daemon). Using XSP would make this much
easier: turning down the webinterface -> kill xsp. No need to restart
beagled or whatsoever (of course we could have some beagled config file
using the .Net configuration framework (if that's implemented in Mono,
dunno), with a key describing whether the webserver should run, add a
SIGHUP handler in beagled which re-reads the config file and
blahblahblah, but that's some (useless?) work again).

Regards,

Ikke
http://www.eikke.com