|
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 |