Re: Beagle Web Interface coming ...



Ikke,
 
If we rely on XSP, then Beagle web access is tied to XSP. For one, users may not want xsp installed at all or they won't be able to start/stop XSP independently, without affecting Beagle web access. You can look at GoogleDesktop, which also provides an integral web access using a builtin minimal web server.  Having a Firefox search bar that directly connects to your Beagle and shows results on the browser is a cool thing to have.
 
Also, I don't understand how you can have a xsp web app directly make a call to a running beagled daemon without using any IPC. Remember beagled  daemon is started and running before the webapp is invoked - if the web app had to launch the beagled and then access it, that would be possible.
I agree with your point that some users may not want this and it is a good idea to provide an option to disable it at compile time and/or runtime.
 
I would also like to hear from other Beagle users what they think about having a Beagle web interface.
 
cheers
Vijay

>>> Ikke <eikke eikke com> 02/06/05 5:18 PM >>>
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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]