Home » Archived » BIRT » Is BIRT good for Eclipse?
| Is BIRT good for Eclipse? [message #40] |
Mon, 20 September 2004 15:54  |
Eclipse User |
|
|
|
Originally posted by: kscott.visualmining.com
We have read the BIRT proposal and related information in the press and
on the Actuate web site and welcome this opportunity to comment.
First, a disclosure. Our company, Visual Mining, currently provides
proprietary solutions containing most of the features defined in the
proposal: A Java codebase, an XML-based report definition, a report
layout engine, a chart rendering engine, a web based report designer and
an Eclipse-based report designer. Our Eclipse-based tool allows users to
create dynamic dashboards and interactive graphics-rich reports. Wizards
guide the developer through the process of interacting with data sources
and designing charts and tables. A graphical layout editor allows users
to drag and drop charts and tables to create complete reports. A code
generation module converts our XML-based report definition into JSP code.
Second, an endorsement. We support the idea of open source business
intelligence reporting tools similar to those outlined in the BIRT
proposal. As a company we would stand to benefit from such tools. We
could easily adapt our chart and report engines to handle BIRT-like
report templates. Our professional services organization has tremendous
experience building and deploying business intelligence applications and
BIRT-like tools would simply expand the set of technologies we draw from.
We have great respect for the Eclipse Foundation and the work that it
does and we are keenly interested in its continued success. It is in
this spirit that we pose these questions to the Eclipse community:
How well is the BIRT project aligned with the Eclipse organization
mission? There is a great deal of work defined here that appears to be
only tangentially related to Eclipse. In our experience, the development
of our XML report format, charting engine and the production report
engine had to be well advanced before any useful Eclipse-related work
could begin.
Most other Eclipse projects target production environments that already
exist. The WTP, Pollinate, WSVT and the Voice Tools project all target
existing environments and standards. The BIRT project seems unique among
Eclipse projects in that it needs to first define the standard for
operating in a space (business intelligence and reporting), then create
production environments that implement that standard before it can
finally create an Eclipse-based tool to develop applications for that
space. Is it in Eclipse’s best interest to sponsor such a widely scoped
project?
The Eclipse Strategic Developer leading this proposal effort, Actuate,
has suggested it plans on making a major part of it’s BIRT contributions
through its new Shanghai Development Center.
( http://www.cbronline.com/article_news.asp?guid=70F9AADC-ADDB -4B4B-86C3-97870F5BFA82)
It appears this center is staffed largely with employees new to Actuate.
Will the Eclipse/BIRT project be able to best leverage Actuate’s
expertise in Business Intelligence through these resources?
Upon initial consideration the Java Community Process or Apache seem
like a more logical home for this project, with an Eclipse sub-project
following its success. Actuate said that it chose Eclipse.org as the
home for BIRT in part to leverage “the momentum of the Eclipse
Foundation”. We are sure that Eclipse would be good for BIRT, we are
less sure if BIRT would be good for Eclipse.
Regards,
Kevin Scott
Vice President of Engineering
Visual Mining, Inc.
|
|
| |
| Re: Is BIRT good for Eclipse? [message #44 is a reply to message #40] |
Tue, 21 September 2004 14:26  |
| Eclipse User |
|
|
|
Kevin,
It seems your two main points are that: 1) the staff Actuate is using to
develop BIRT is not experienced in the BI arena, and 2) there are no
existing standards for reporting and it's not appropriate for Eclipse to
lead the charge in creating them.
To your first point, I can assure you that the staffing for the project will
leverage Actuate's full ten years of experience in the reporting and BI
space. Committers to the project will include employees with significant
tenure with the company, including very senior engineers who co-founded the
company.
The staff in our Shanghai development center will also be contributing, but
they are far from inexperienced, and in fact, were instrumental in
developing our first commercial product based on Eclipse: Actuate's
Information Object Designer (IOD). The IOD is the graphical design
environment for enabling access to disparate data sources through our
Enterprise Information Integration (EII) technology. While IOD is not part
of the BIRT initiative, our developers' extremely positive experience in
both Shanghai and South San Francisco with Eclipse for the IOD product was a
factor that led to our BIRT proposal.
To your second point, I believe that part of the appeal of the BIRT project
to Eclipse and the Eclipse community is that it opens up new markets for the
platform and expands the user base for the technology. Furthermore,
reporting is very natural extension to the Java and web applications
technology that is currently supported within Eclipse and a lack of
standards in the area (with the possible exception of Microsoft's RDL)
should not be accepted as a roadblock to development of BIRT.
There are very strong synergies between the BIRT project and others within
the foundation, including the Test & Performance Tools Platform Project. I
know from our conversations with the PMC leadership of that project that
charting is coming to Eclipse regardless of whether BIRT brings it. Member
companies in Test & Performance Tools are considering donation of charting
technology, and our discussions have centered on how to combine the efforts
to provide a charting module that can meet the needs of all Eclipse
projects
|
|
|
| Re: Is BIRT good for Eclipse? [message #45 is a reply to message #40] |
Tue, 21 September 2004 14:34 |
| Eclipse User |
|
|
|
There appear to be two types of concerns being raised here. For clarity
sake, I will reorder the original document to classify the concerns as
follows, then offer my opinion. (This is my opinion and generally the
stance of ASC, not the stance of the Visual Editor Project on which I
serve or of Eclipse.org.)
Your last questions get to what I think is the heart of the matter:
1) Is BIRT even within Eclipse's scope or (how/when) should Eclipse as a
practical matter restrict its scope?
> Actuate said that it chose Eclipse.org as the
> home for BIRT in part to leverage “the momentum of the Eclipse
> Foundation”. We are sure that Eclipse would be good for BIRT, we are
> less sure if BIRT would be good for Eclipse.
Here are the criteria ASC believes should be applied to determine if a
proposed feature is "good for Eclipse", by which we mean, "good for the
Eclipse ecosystem":
Q1) Is there some constituent in the Eclipse ecosystem that is served
significantly better by adding the proposed feature to Eclipse? ASC
believes that this is the primary principle that defines if a particular
feature is in or out of Eclipse's scope.
Justification and explanation:
- Eclipse is first and foremost an ecosystem of vendors, open-source
developers, and users (I'll get in trouble with somebody no matter how I
order that last list... ;-), not a piece of technology. Something isn't
in Eclipse's scope just because it makes technical sense, but because it
makes sense for significant constituents in Eclipse's ecosystem.
- Eclipse has two primary constituents: the open-source community and
commercial interests. One or the other (preferably both) needs to be
clearly served better as a result of a proposed feature being added to
Eclipse.
- Merely saying that now the commercial interests can get something
royalty-free is not sufficient. They must be able to do something they
couldn't reasonably do before. Eclipse.org is not about handing out
free lunches.
- On the other hand, the open-source community works on Eclipse's
behalf, royalty-free. Some people invest significant amounts of
personal time (without earning a dime) writing code, writing nice things
about Eclipse, entering and discussing solutions for defects.
Therefore, saying that these folks who are working for free to begin
with can get something royalty-free *is* a legitimate argument.
Q2&3) Is there a clear need for the new feature to be in Eclipse itself
because of some feature that Eclipse itself needs to provide? (3) If
so, are we doing more long-term good than harm to the Eclipse ecosystem
by the *way* in which we add the proposed feature?
Justification and explanation:
- Sometimes Eclipse itself just needs to evolve. In that case, we need
to do as little harm as possible to the ecosystem in the process.
-----
Let's apply this to BIRT:
1) I think it's clear that the open-source community and many commercial
companies alike will benefit from having something like BIRT. Something
like BIRT is definitely needed in order for RCP to take off in certain
market segments. Also BIRT would complement various vendors' products
tremendously.
Due to this answer, I conclude that BIRT (in the abstract) is definitely
in Eclipse's scope.
This leads to the second category of questions:
2) Is Eclipse *technically* the appropriate forum; is the technical
approach being proposed optimal?
> How well is the BIRT project aligned with the Eclipse organization
> mission? There is a great deal of work defined here that appears to be
> only tangentially related to Eclipse. In our experience, the development
> of our XML report format, charting engine and the production report
> engine had to be well advanced before any useful Eclipse-related work
> could begin.
From the Eclipse home page, "Eclipse is a kind of universal tool
platform - an open extensible IDE for anything and nothing in particular."
That sounds pretty open-ended to me--like on technical principle Eclipse
could wind up including just about anything.
> Most other Eclipse projects target production environments that already
> exist. The WTP, Pollinate, WSVT and the Voice Tools project all target
> existing environments and standards. The BIRT project seems unique among
> Eclipse projects in that it needs to first define the standard for
> operating in a space (business intelligence and reporting), then create
> production environments that implement that standard before it can
> finally create an Eclipse-based tool to develop applications for that
> space. Is it in Eclipse’s best interest to sponsor such a widely scoped
> project?
Here I generally agree. I'm not a BI guy, but from where I sit, it
would seem like BIRT should adopt Jasper Reports
(http://jasperreports.sourceforge.net) as its reporting engine if it
would either meet their needs or could be adapted to meet their needs.
It's much easier to start an open-source project with something then to
start from nothing. If you can start with either technology or a
community, you're ahead. Jasper Reports possibly could provide the
opportunity to start with both, a huge advantage.
> Upon initial consideration the Java Community Process or Apache seem
> like a more logical home for this project, with an Eclipse sub-project
> following its success.
I guess I don't agree since I think that BIRT (in the abstract anyway)
is well within Eclipse's scope, both from a community and from a
technical perspective.
Regards,
Dave Orme
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com http://essentialdata.sf.net
|
|
| | | |
| Re: Is BIRT good for Eclipse? [message #70 is a reply to message #67] |
Sun, 03 October 2004 18:30 |
| Eclipse User |
|
|
|
Ilias,
There appears to be a misunderstanding. The Eclipse Foundation is not a
standards organization, nor does it intend to ever be one.
There is nothing within BIRT which will be standardized at Eclipse or by
Eclipse. Can you please clarify what you think we are attempting to
standardize?
-------
Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.
"ilias" <ilias@lazaridis.com> wrote in message
news:opse84jcflrp2aut@news.eclipse.org...
> On Mon, 20 Sep 2004 15:54:49 -0400, exquisitus <kscott@visualmining.com>
> wrote:
>
> > We have read the BIRT proposal and related information in the press and
> > on the Actuate web site and welcome this opportunity to comment.
> [...]
>
> I have read your message and some of the replies, which were mostly
> disapointing for me [they do not have an "interview character", asking you
> to evaluate your objections a little bit more].
>
> [I would do this now, but I am already out of timeline and must close the
> eclipse.org case]
>
> I was wondering what will happen with the birt project charter approval.
>
> "Approved unanimously by the eclipse Board".
>
> -
>
> [general comments]
>
> -
>
> BIRT is not good for eclipse.
>
> But it is not the fault of BIRT directly.
>
> "BIRT" is simply the first "we do it all ourselves, including the
> standard".
>
> This model will attract new members (which would like a similar project)
> and in the same moment distract others (which do not like to see to much
> centralized control).
>
> -
>
> The respect I have for eclipse.org is lowered due to this case.
>
> And I start to distrust eclipse.org.
>
> -
>
> Actuate should release eclipse.org from this situation. They should pull
> the break and move the standards part of BIRT to a neutral entity outside
> of eclipse.org (e.g. Apache), whilst dedicating developers there.
>
> This way, "visualmining" and other companies would join this effort much
> easier.
>
> -
>
>
>
> Please provide clear project directives:
>
> e.g.: "Standard definition is out of the eclipse.org projects scope"
>
> -
>
> Clear seperation of
> - the standard [outside eclipse.org]
> - tool creation framework (based on the standard)
> - tools (based on the framework)
> - example tools
> - open source tools
> - commercial tools by vendors
>
> -
>
> It's to early for eclipse.org to become a OSSO (Open Source Standards
> Organization)
>
> The eclipse.org project infrastructure is too inefficient and
> intransparent.
>
> [/ECLIPSE.ORG]
>
> .
>
> --
> eclipse.org.project
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=73282
>
> -
> http://lazaridis.com
|
|
|
| Re: Is BIRT good for Eclipse? [message #72 is a reply to message #70] |
Sun, 03 October 2004 22:43 |
| Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
On Sun, 3 Oct 2004 18:30:11 -0400, Mike Milinkovich
<mike.milinkovich@eclipse.org> wrote:
[moved manually down into context by ilias]
>
>
> "ilias" <ilias@lazaridis.com> wrote in message
> news:opse84jcflrp2aut@news.eclipse.org...
[...]
>> BIRT is not good for eclipse.
>>
>> But it is not the fault of BIRT directly.
>>
>> "BIRT" is simply the first "we do it all ourselves, including the
>> standard".
>>
>> This model will attract new members (which would like a similar project)
>> and in the same moment distract others (which do not like to see to much
>> centralized control).
>
> There appears to be a misunderstanding. The Eclipse Foundation is not a
> standards organization, nor does it intend to ever be one.
>
> There is nothing within BIRT which will be standardized at Eclipse or by
> Eclipse. Can you please clarify what you think we are attempting to
> standardize?
When I refere to "standard" i mean essentially a "quasi-standard".
If BIRT creates a definition, actuate, ibm, intel, hp, ... will adopt it.
A quasi standard (which will possibly become a formal standard one day.)
-
Some quotes (from within this thread) confirm the need for a
[quasi]standard:
Quote from OP, Kevin Scott, <kscott@visualmining.com>"
"The BIRT project seems unique among Eclipse projects in that it needs to
first define the standard for operating in a space (business intelligence
and reporting)"
Quote from "Mark Coggins" <mcoggins@actuate.com>
"[...]It seems your two main points are that: 1) [...], and 2) there are
no existing standards for reporting and it's not appropriate for Eclipse
to lead the charge in creating them."
"[...]and a lack of standards in the area (with the possible exception of
Microsoft's RDL)
should not be accepted as a roadblock to development of BIRT"
"[...]I also believe that the Eclipse community is a very appropriate
forum in
which to promulgate the development of an open source platform for
reporting
(including an XML-based specification). I don't see why the Java community
at large (of which Eclipse is surely a very important constituent) or
Apache
would necessarily be better places to establish it."
-
Everything is fine.
Except: the "XML-based specification" (and everything else which has the
nature of a [quasi]standard specification).
This should be moved outside of eclipse.org, in the interest of
eclipse.org and the BIRT project.
-
I would expect those step from ACTUATE:
They should invite "visualmining", "JasperAssistant" and others to define
the "BIRT" [quasi] standard @apache (or an other similar foundation).
[I've nothing to do with this companies / organizations. Just interested
in the success of eclipse - although I will possibly use finally netbeans].
I would expect the steps below ([ECLIPSE.ORG] tag) from eclipse (standard
= {standard|quasistandard})
-
>> The respect I have for eclipse.org is lowered due to this case.
>>
>> And I start to distrust eclipse.org.
>>
>> -
>>
>> Actuate should release eclipse.org from this situation. They should pull
>> the break and move the standards part of BIRT to a neutral entity
>> outside
>> of eclipse.org (e.g. Apache), whilst dedicating developers there.
>>
>> This way, "visualmining" and other companies would join this effort much
>> easier.
>>
>> -
>>
>>
>>
>> Please provide clear project directives:
>>
>> e.g.: "Standard definition is out of the eclipse.org projects scope"
>>
>> -
>>
>> Clear seperation of
>> - the standard [outside eclipse.org]
>> - tool creation framework (based on the standard)
>> - tools (based on the framework)
>> - example tools
>> - open source tools
>> - commercial tools by vendors
>>
>> -
>>
>> It's to early for eclipse.org to become a OSSO (Open Source Standards
>> Organization)
>>
>> The eclipse.org project infrastructure is too inefficient and
>> intransparent.
>>
>> [/ECLIPSE.ORG]
>>
>> .
--
http://lazaridis.com
|
|
| |
| Re: Is BIRT good for Eclipse? [message #77 is a reply to message #76] |
Thu, 07 October 2004 02:29 |
| Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
On Wed, 6 Oct 2004 19:52:28 -0400, Mike Milinkovich <mike.milinkovich@eclipse.org> wrote:
[context partly recreated manually by ilias]
>> Except: the "XML-based specification" (and everything else which has the
>> nature of a [quasi]standard specification).
>
> Here is our thinking.....
>
> We believe that it would be rather arrogant of us to assume that just
> because a project at Eclipse creates an XML schema that it will
> automatically be: (a) adopted by the world or
not the "world", but eclipse members and eclipse technology users
(which most possibly will be enouth).
quote:
>> If BIRT creates a definition, actuate, ibm, intel, hp, ... will adopt it.
-
> (b) of immediate interest to any standards organization.
not immediate.
quote:
>> A quasi standard (which will possibly become a formal standard one day.)
-
But I've understood the essence of the paragraph.
-
>> This should be moved outside of eclipse.org, in the interest of
>> eclipse.org and the BIRT project.
>
> Our intent to to gauge the success of BIRT. This evaluation will be both
> from the robustness of its technology and its degree of adoption by
> commercial users and open source projects.
ok
> If BIRT becomes successful enough to warrant standardization of the report
> definition, then we will definitely do so. And it will be done at an
> organization other than the Eclipse Foundation.
This sounds rational.
=> {Standard Incubation}
> The immediate requirement that the Eclipse Foundation laid upon the BIRT
> team was to ensure that the XML definition was open source licensed from day
> one so that everyone had equal access to it.
CPL/EPL compliance should be a basic requirement for all projects.
An eclipse team should _never_ have the possibility to do 'undercover' developement.
> We believe that this is the appropriate step at this point in time.
I understand.
But I believe that open source access is not enouth.
Companies from the BI and RT sectors should feel comfortable with the project
They should have an influence on the design.
And I mean a _real_ influence.
Possibly the specification part of the BIRT project should be encapsulated in an BIRT subproject, where contributors from other companies would be invited to join.
Organizing the specification part in an subproject would simplify a possible future move to another location outside of eclipse.org.
=> {Standard Incubation Subproject}
-
Clearly stated directives should define how eclipse.org treats "Standard Incubation Subprojects".
This would increase trust into eclipse.org, attracting more companies and users.
-
Directives are important.
Prime Directives are _very_ important.
I am missing those "Prime Directives" within eclipse.
see:
[ECLIPSE.ORG] - The Prime Directives of Ethical Business
http://www.eclipse.org/newsportal/article.php?id=30461&g roup=eclipse.platform
..
--
http://lazaridis.com
|
|
|
| Re: Is BIRT good for Eclipse? [message #79 is a reply to message #77] |
Thu, 07 October 2004 07:33 |
| Eclipse User |
|
|
|
"ilias" <ilias@lazaridis.com> wrote in message
news:opsfhlnoggrp2aut@news.eclipse.org...
>
> > We believe that this is the appropriate step at this point in time.
>
> I understand.
>
> But I believe that open source access is not enouth.
>
> Companies from the BI and RT sectors should feel comfortable with the
project
>
> They should have an influence on the design.
>
> And I mean a _real_ influence.
>
> Possibly the specification part of the BIRT project should be encapsulated
in an BIRT subproject, where contributors from other companies would be
invited to join.
>
> Organizing the specification part in an subproject would simplify a
possible future move to another location outside of eclipse.org.
>
I don't think this is a good idea for two reasons...
....it violates a basic open source principal that the folks that are willing
to do the work get to make the decisions. I mean, that's that's the very
nature of the Eclipse consortium, that the members willingly contribute code
and resources for free because it's in their own best interest to develop a
thriving community that will integrate the results into their businesses.
No member would sign up just for the privilege of taking their marching
orders from a horde of other companies with nothing but opinions.
Take SWT for instance, can you imagine that SWT would ever have happened if
IBM had given the java community any real influence on the design process?
No, it wouldn't. Instead IBM did what it felt was in it's best interest
(developing a lightweight, cross-platform, widget platform, with tight
integration to the host OS). The only decision that the community has to
make is whether or not they like the results and whether they want to use
the results. And that's the way it should be. (BTW, I work for a small
company that is an Eclipse consortium member wannabe, but we're still too
small to contribute as a member, so we play our part in the community by
making the contributions that we can).
....design by committee is generally not a good thing.
--
Ted Stockwell
Technical Director
rpcsoftware.com
|
|
| | | |
| Re: Is BIRT good for Eclipse? [message #95 is a reply to message #91] |
Fri, 08 October 2004 18:31 |
| Eclipse User |
|
|
|
I'd like to re-visit one of my earlier postings because it relates
strongly to this thread. We have grappled with this "force a standard
into an established unstandardised space" problem in Hyades/TPTP for a
long while. You can try and do it but you'll piss off everyone already
in the space unless there is upside to them in moving. In the case of
Hyades it is the Test Script that causes the problem. We (Scapa) have
one (or possibly even 2). Mercury has several, Compuware have several,
and IBM Rational have probably got dozens. Then there's a whole stack of
JUnit Derivatives with their own scripting laguages being born almost
every day. Within this space you simply can't drive a standard and hope
to get traction. We even have an advantage of a confirmed standard at
the OMG (U2TP). So, we have taken the approach of offering a phased
adoption whereby vendors can plug in to bits of the framework without
necessarily picking up any of the central standard, there is also a
"cat-flap" int he standard which allows partial adoption, and finally
there is full adoption. We are at partial adoption. Most of Rational's
soon-to-be released products are at partial adoption.
The details of how this works are on my last post
news://news.eclipse.org:119/cgkel1$46l$1@eclipse.org
You should note that TPTP/Hyades now has broad industry support (Scapa,
IBM, SAP, Compuware, CA, HP FOKUS). I am sure this is the right way
forward for BIRT
Mike
ilias wrote:
> On Thu, 7 Oct 2004 06:33:37 -0500, ted stockwell <emorning@yahoo.com>
> wrote:
> [...]
>
> I've read and understood your objections.
>
> You _describe_ the general status-quo.
>
> -
>
> I _criticizing_ exactly this status-quo.
>
> I suggest organisational changes - at least for the _parts_ of a project
> that contain a possible standardization of a domain.
>
> I you have specific questions to my previous writings, let me know
> (please write in context).
>
> cu!
>
> .
>
|
|
|
| Re: Is BIRT good for Eclipse? [message #97 is a reply to message #95] |
Sat, 09 October 2004 00:12 |
| Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
On Fri, 08 Oct 2004 23:31:01 +0100, Mike Norman <mgn@scapatech.com> wrote:
> ilias wrote:
>
>> I suggest organisational changes - at least for the _parts_ of a project
>> that contain a possible standardization of a domain.
>
> I'd like to re-visit one of my earlier postings because it relates
> strongly to this thread. We have grappled with this "force a standard
> into an established unstandardised space" problem in Hyades/TPTP for a
> long while.
[...]
> We even have an advantage of a confirmed standard at
> the OMG (U2TP). So, we have taken the approach of offering a phased
> adoption whereby vendors can plug in to bits of the framework without
> necessarily picking up any of the central standard, there is also a
> "cat-flap" int he standard which allows partial adoption, and finally
> there is full adoption. We are at partial adoption. Most of Rational's
> soon-to-be released products are at partial adoption.
Very nice!
=> {Phased Adoption Framework}.
> The details of how this works are on my last post
>
> news://news.eclipse.org:119/cgkel1$46l$1@eclipse.org
many details.
I don't understood them all.
[but your writings in this thread had enouth detail for me]
> You should note that TPTP/Hyades now has broad industry support (Scapa,
> IBM, SAP, Compuware, CA, HP FOKUS).
ok
> I am sure this is the right way forward for BIRT
I agree fully.
Most possibly, this is the right way for all projects with a similar standardization/adoption problem (even for existing and mature projects).
And not every project should invent the wheel again.
-
This looks like a new "eclipse.technology" project.
"Phased Adoption Framework" [example naming]
[will post a followup shortly]
..
--
http://lazaridis.com
|
|
| | |
| Re: Is BIRT good for Eclipse? [message #107 is a reply to message #105] |
Wed, 13 October 2004 00:22 |
| Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
On Mon, 11 Oct 2004 14:22:25 -0400, Chris <schtoo@schtoo.com> wrote:
>
> "ilias" <ilias@lazaridis.com> wrote in message
> news:opsfi3hsanrp2aut@news.eclipse.org...
>> On Thu, 7 Oct 2004 13:18:10 -0400, Chris <schtoo@schtoo.com> wrote:
>>
>>>> ...design by committee is generally not a good thing.
>>>
>>> Amen!
>>
>> Instead of writing off-topic 'religious' content, you should better
>> correct your website.
>>
>> http://www.schtoo.com
>>
>> it fails with:
>>
>> Mozilla 1.7.2
>> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
>
> You are ridiculous.
"ridiculous"
> Perhaps we'd all be better off if you'd just go do your
> squawking somewhere else.
"squawking"
Please use mental and technical methods to ignore any public writings that you dislike.
> ps. Ooops wait, I didn't mean to post off-topic 'bird-related' content. ;)
Apology granted.
..
--
http://lazaridis.com
|
|
|
Goto Forum:
Current Time: Tue Nov 04 02:51:43 EST 2025
Powered by FUDForum. Page generated in 0.46079 seconds |
Home