Re: [Xweb-developers] Reactivating development

[Peter B. <pe...@pe...>]

murphee (Werner Schuster) wrote:

>>> Peter Becker wrote:
>>> murphee wrote:
>>>
>>>> Your bus described in the presentation -- is that a Bean InfoBus?
>>>
>>> Nope, but it was influenced by it InfoBus (and jEdits EditBus);
>>> Webbuilder was designed to be very extensible and something like
>>> that was necessary for that;
>>
>> What was the reason not to go with an InfoBus? I am currently trying to
>> understand the Bean world and I wonder if I should use some of the ideas
>> in XWeb itself.
>
>
> InfoBus is basically for connecting data sources; if I remember 
> correctly, it was built by Lotus (for their e...-something Java office
> suite) and then donated (or something like that) to Sun ... who 
> immediateley started working hard on ignoring it... sometimes I really
> don't understand what the people at Sun are thinking (same thing with
> Jini, which, after the first months of press-brooha, was simply 
> ignored...);

Sun is a big company, you have to expect a bit of SNAFU in there :-) And 
it seems neither you nor Hendrik were two impressed with the InfoBus.

> Well, anyway the Bus & Channel structure in Webbuilder is for
> sending Events; the idea was basically stolen from jEdits EditBus;
> One thing I changed was to allow for several channels; the reason
> was to make the whole thing scaleable; if all Events are sent on one
> bus, everyone gets every Event (as far as I understood EditBus); if
> the application reaches a certain amount of traffic, that must be
> limiting performance;

Sounds quite like the EventBroker class I use in our applications. It 
implements a publish/subscribe pattern based on event hierarchies. Each 
broker creates an event context, to which listeners can subscribe. 
Brokers are listeners themself to allow event delegation without 
bridges. The performance is probably not too good, though -- we rely 
heavily on RTTI for this, both the event and the subject of the event 
get checked via "instanceof". Never profiled it against simpler 
approaches, although I suspect that for application-level events it is 
probably not that important. Our 2D canvas class still uses it -- that 
should probably be fixed towards using a standard listener interface.

[..]

>
>>> Oh yeah... running JTidy before Xweb would be useful, if you want
>>> to import non-XHTML input files (this would make XWeb more 
>>> userfriendly,
>>
>> I defintely want JTidy support within XWeb, it seems to be too important
>> to need extra tools. The XHTML requirement for things like the generic
>> stylesheet coming with the distribution is a bit of a drawback.
>
>
> Hmm... how do you want to integrate JTidy into XWeb? Simply call it 
> before using an input file? Or if the XML Parser complains that the
> file is not well formed;

This is more for the stream idea. What I'd like to do is something like 
this:

<process ...>
  <jtidy/>
  <xslt .../>
  <xslt. .../>
</process>

The file would start of as a standard IO stream, and gets passed to 
JTidy as such. The JTidy output would still be an IOStream (I guess), 
but it should be implicitely converted to SAX since the XSLT would use 
SAX. Between the two XSLTs no conversion would be necessary, at the end 
the SAX stream would be turned into an IOStream for output. The idea 
would be defining these processes somewhere and using them in the docTypes.

>> chance to be found than yet another SF project without any activity. But
>> it's your choice of course. And there is the licensing issue, at the
>> moment XWeb is still public domain. The thing with licenses is that I
>> don't really want to care, but sometimes I feel I should :-)
>
>
> er... when you say public domain, you mean GPL? (Can't remember what
> XWebs license was...);

No, public domain, which means no license. It means anyone can do 
anything with it, a bit like not being owned. The only problem I have 
with this approach is that it has no warranty exclusion and 
unfortunately we live in times where people try to take less and less 
responsibility for what they do ;-)

I am not a fan of the GPL since I don't like telling people what to do. 
Not that I am not opiniated, but in the end everyone should do what they 
think is right. And revolutions tend to create new governments :-)

I prefer BSD- or Apache-style since simple and quite basic, or the Open 
Software License with the anti-IP attitude 
(http://www.opensource.org/licenses/osl-2.0.php), but unfortunately as 
easy to read as the average EULA -- which is a rather bad feature.

Personally I am quite willing to take the risk of the PD approach, but I 
suspect that before I accept contributions I should probably handle the 
licensing question.

  Peter