[9fans] Re: allowing abaco to receive plumber messages

[9fans] Re: allowing abaco to receive plumber messages

[Federico Benavento]

On 11/15/05, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> wrote:
> > > I don't know if this is what you want:
> >
> > Hmm, I don't know either, I had thought about this too.
> > As you say making it a plumb server allows you to
> > click on in the same window. but you loose the open a
> > link in a new window capacity.
>
> Yes, I see there are choices that can be made and it is
> not yet clear what is the best solution.
>
> Being aware of this, and not being burdened by having
> to implement it, for me it is easy to say:
> I think, for now, while we (you, your users) are still
> trying out what works best, it might be best/nicest to have
> a very flexible tool, that can be used in various ways,
> to allow experimentation, to see what works best.
>
> I'm wondering if it would be possible/useful to make
> a separation between the 'core' rendering thing
> (as abaco does) and the navigational stuff around it,
> 'the manager' that keeps track of history etc.
>
> I don't know what is best:
>  - in some cases you just want to reuse the window for a new page
>  - in some cases something like tabbed browsing is nice
>  - in some cases you may want a new window
>
> It might be nice (but I don't know if possible) to have
> an 'open' framework that would allow you to have/build
> all of these in an easy way, and abaco would be (re)used
> in all cases.
>

I'm rewriting abaco to use thread(2), and right know my testing
threadmain only calls 2 functions:

HText *htload(Rune *);
void htrender(HText *, Image *, Rectangle);

> Would the Plan 9 drawing approach make things easier?
> E.g. abaco just renders a url onto a given window
> (drawing device), and somehow (plumbing?) gives access to
> the links in there.
> Then the real browser (gui) just manages windows (drawing devices),
> a bit like rio does, but then specialized for web browsing,
> also with navigational buttons or so,
> either overlaying/next to each other (tabbed browsing),
> or by creating new windows, or ...
> a bit like ghostview (the postscript engine) renders inside
> a gv window on unix.
>
> > My idea was this: if you want a page to be open in the same
> > abaco instance you click on the link, and if you want to open it
> > in another window you just plumb the link.
>
> makes sense. Can you already click a link to open it?
> If so, I missed it...
>
no, you can't do it right now.

> > I still, don't know what is better, and still thinking,
> > how the UI should be, what I do know is that I need
> > to rewrite abaco with threads and change the rendering model:
> > no double buffering, because some pages are too large, and
> > allocimage fails, and avoid non needed calculations.
> >
> > If you have more opinions(pros & cons) about making it
> > a plumb server, or about the UI, or just about anything.
> > I'll be glad to hear them.
>
> Some ideas above.
>
> It might interesting to see if indeed it is possible to
> keep abaco as simple as possible (let it do one thing and
> do it well: render a page, and send url's to the plumber),
> and build all stuff the user might like outside 'abaco-core',
> where indeed, hopefully, the plan 9 ways of doing things
> (/dev/draw, plumbing) make it easy to do build an application
> as a collection of small program, working together concurrently
> to get the job done (as actually you are already doing,
> of course, with webfs and maybe also other stuff I'm not aware of).
>
hmm... I'm more inclided more for a lib solution.

>
> Thinking in this context, maybe abaco-core should not
> directly accept the web plumber message: they should
> go to the 'surrounding' browser gui, which then decides
> wether to forward it to an existing abaco instance
> (which one? the one that generated the plumb request?
>  but how do we identify that one?)
> or to a new pane (as in tabbed browsing) or even new window,
> and then just sets up the right window context (a la rio)
> before invoking abaco-core to do the rendering.
>

maybe the best/simpler solution would be having a command line option
"-p" that makes that abaco instance a plumb server, but I'm not sure.


--
Federico G. Benavento