Johann,
All that would be required is to take a already existing web-service
lib, and use the DSO (dynamic shared object) support in XE to pull it
into SXE. The whole idea behind a web service is to eliminate the
need for a web-browser to use web-based application/services. So we'd
use whatever xemacs uses for it's UI to tie into the web service DSO
stuff. Granted that's if we go with my crazy idea of abstracting
bugzilla. Which in all open mindedness seems pretty much overkill.
But to accomplish Steve's ideas/goals/brain farts (hehe), it's
definitely a possibility. Now I don't know much about bugzilla, but
it would be cool if they already had a web-service, and that would
eliminate this course of thought. Another option is to just go with
bugzilla for bug tracking, as Erik suggested.
Nick
On Mon, 16 Aug 2004 19:53:48 +0000, Johann Gunnar Oskarsson
<johann@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> heat sink writes:
> > I think this could easily be a web-service. We'd have a dedicated
> > server that takes care of all of the login information for bugzilla.
> > And then we'd have a standalone front-end and a built-in (in SXemacs)
> > front-end to the service. We basically facade or abstract all of that
> > nasty bugzilla information from the user when he/she submits a bug
> > report. This also allows us to pipe that bug submition not only to
> > bugzilla via the server backend, but also allows us to pipe it out to
> > everyone, respond to the user, and even if we make it smart enough
> > parse the bug report and send it to certain members of the team for
> > resolution.
>
> > Now the question remains.....how does lisp become web-service savvy.
> > I highly doubt anyone has written a web-service library for it. So my
> > next question would be can lisp access shared object libraries? I'm
> > sure it can i'm just wondering how much of a boogle that would be on
> > performance.
>
> Well, there *is* the DSO (dynamic shared object) support in XE and
> using it to implement something like a web browser has just ... not
> been done yet.
>
> The *could* be done with the following recipy:
>
> Paste the w3m C code into the DSO file.
>
> Rewrite parts of emacs-w3m in C to make the binding in the C part.
>
> Ok, this is not really a realistic approach, but for interfacing web,
> something similar is probably best. To actually have a web browser
> built-in (err, linked in).
>
> We could also make this use anything else we can think of for
> protocol.
>
> Well, this brings me to another issue, documentation.
>
> A Sexy Macs, needs Sexy Docs. And the current way of generating docs
> is ... horrible.
>
> What I want:
>
> * Translatable doc strings!
>
> I'm not sure gettext is the best/only solution, so I'll be looking
> into stuff.
>
> * Cross references between the doc strings and the manuals.
>
> Whatever happens, I *insist* on this.
>
> * The manuals in something else than info for online reading
>
> If we implement html parser for Sexy, then we can use that. Please
> note that we can use the META tags to provide the UP, NEXT, PREV
> links. I even think the html standard provides such META tags
> .... (trying to recall stuff I read in '96 ... can't be sure, or if it
> was just examples of possible use of META ...).
>
> In this world of text rendered html, there are no real arguments
> against that. And I think we should be using a subset of it anyway.
>
> * No duplicated info in the doc strings and the manuals.
>
> This is just horrible to maintain. For printed manuals, we can
> provide way(s) to include doc strings into the rest. (And that info
> should mostly be in appendixes anyway).
>
> Have fun,
>
> Johann
>
>
--
Samir: No one in this country can ever pronounce my name right. It's
not that hard: Na-ee-ana-jaad. Nayanajaad.
Michael Bolton: Yeah, well at least your name isn't Michael Bolton.
|