[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [birt-dev] Bugzilla 173217 - BIRT Report Delivery ProposalandPatch Review Request
|
Hi Wei Yan, Hongchang:
Thanks for considering the proposal. I suppose it
depends on how one look at the exact definition of a
Report Engine. I certainly can see that its primary
goal is for report generation and rendering. But from
the current RE API perspective, I see that it does
more than report rendering. (e.g. it can perform data
extraction as an engine task).
Anyhow, the initial prototype was just a quick way for
proof of concept and most of the machinery(i18n,
extension loading) are already implemented in the
Report Engine, so it was convenient to reuse these
code rather than to have a separate engine.
The report delivery feature that I am proposing can
well be its own BIRT engine that the Report Server or
Report runner can invoke. Either way, I think the
report delivery proposal is a useful addition to BIRT
and its community.
The main point that I was trying to convey is, in
order to perform report delivery, the current emitter
API needs to be addressed first as described in the
proposal document.
1) There is currently no systematic way of getting all
the rendered files of a report, especially in the case
of HTML reports. (i.e.: HTML and its associated
images including static images and charts) If this
information is not available from the RE then it is
difficult to send the report as HTML mail with its
images inline or as attachments.
2) When the rendering output options(filename or
stream) are *not* specified, the emitter
implementation is free to generate its own file output
name. However, there is no way to query this output
filename from the emitter API or report engine. The
RE does not enforce what the default filename should
be.
3) Having all the rendered files information from the
Report Engine is useful for report cleanup, especially
in the case where the image directory is shared by
different report engines. I don't see why an
application has to custom code this logic when the
information can be supplied by the report engine
system itself.
4) If I think of BIRT as a BI platform rather than
just a reporting tool, then I believe that Report
Delivery should be considered in the BIRT domain and
it is really part of the life cycle of a report.
5) Email is a very common way of report delivery, so I
can see that it is a useful feature and a good
integration point for BIRT to have a general report
delivery mechanism. To address this further, the
delivery solution should be extensible so that BIRT
developers can implement their own delivery
requirement.
Comments?
Regards,
Yip Ng
--- Wei Yan <wyan@xxxxxxxxxxx> wrote:
> Report engine should only focus on report generation
> and rending.
>
> The report delivery feature is part of report server
> which uses the
> report engine to generate the report.
>
> I think it is not in the BIRT domain.
>
> Thanks.
>
> -Wei Yan
>
>
> -----Original Message-----
> From: birt-dev-bounces@xxxxxxxxxxx
> [mailto:birt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Hongchang Lin
> Sent: Thursday, February 08, 2007 10:04 AM
> To: Yip Ng; birt-dev@xxxxxxxxxxx
> Subject: RE: [birt-dev] Bugzilla 173217 - BIRT
> Report Delivery
> ProposalandPatch Review Request
>
> I think it could be a good additional function for
> BIRT.
>
> -Hongchang Lin
>
> -----Original Message-----
> From: birt-dev-bounces@xxxxxxxxxxx
> [mailto:birt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Yip Ng
> Sent: Thursday, February 08, 2007 2:17 AM
> To: birt-dev@xxxxxxxxxxx
> Subject: [birt-dev] Bugzilla 173217 - BIRT Report
> Delivery Proposal
> andPatch Review Request
>
> Hi birt-dev:
>
> I would like to propose and contribute a new BIRT
> functionality in the area of report delivery to the
> Eclipse BIRT project. Report Delivery is a
> fundamental
> and integral part of reporting.
>
> Initial proposal is to provide a more extensible
> solution for report delivery in BIRT. The solution
> should provide some out-of-the-box delivery
> mechanisms
> such as e-mail, ftp, etc. as well as providing the
> flexibility for the BIRT developers to customize
> their
> report delivery requirements by defining their
> own extensions for report delivery. The custom
> report
> delivery will be provided via Eclipse plug-in
> extension point mechanism.
>
> With the delivery extension defined and integrated
> to
> BIRT, it would be relatively easy to provide other
> custom report delivery mechanisms such as FTP,
> printer, cache, fax, Web Portals, etc.
>
> An initial implementation for the proposal and a
> mail
> delivery extension is supplied with the attachments
> along with the proposal document in Bugzilla 173217.
>
>
> The changes are based on the latest BIRT CVS HEAD
> (v2.2). Please refer to the proposal document for
> further details.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=173217
>
> I would appreciate it if someone would review the
> proposal and the supplied implementation.
>
> If the proposal is feasible, I would like to
> continue
> improve the implementation and work on testing
> aspect
> of this feature. Thank you.
>
>
> Regards,
> Yip Ng
>
>
>
>
>
________________________________________________________________________
> ____________
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.
>
http://answers.yahoo.com/dir/?link=list&sid=396545367
> _______________________________________________
> birt-dev mailing list
> birt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/birt-dev
> _______________________________________________
> birt-dev mailing list
> birt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/birt-dev
> _______________________________________________
> birt-dev mailing list
> birt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/birt-dev
>
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
