gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUe-dev] [RFC] GNUe Reports Server


From: Jan Ischebeck
Subject: Re: [GNUe-dev] [RFC] GNUe Reports Server
Date: Wed, 29 Oct 2003 19:37:30 +0100

Jason, I seem to misunderstood your comment in IRC, as I didn't know
that the report engine interface isn't in a final shape. And now, as you
said it explicit, I remember you had said it before. Damn brain.. But
nevertheless I think, that the existence of a report server is important
as a signal that GNUe can be used by other tools as well. (and I want to
stop dcmwai implementing his own pdf report engine ;) ) 

The code is nothing that cannot be changed and adapted to a new report
engine quickly. As it took longer to write that email than to implement
the stuff.

I think that for now, I just implement the authentication stuff and the
rpc parameter passing, because both is independent from the report
engines API and is both needed to make the server usable. The rest can
wait for later.

Btw. I recently talked with someone from Teradata, the company which
runs Wallmarts OLAP database, and he described the differences of the
different report tools to me. F.e. crystal reports has a better sql
generation engine and ?business objects? has the better user interface.

I don't think that we "should" play in the same league as Wallmarts OLAP
tools and we probably have different goals. But we could/should learn
from this report tools. And I got some impressions of this stuff. F.e. I
think that gnue reports should create better sql and try to move as much
computing as possible in the database itself (if it isn't gadfly or
sqlite :) . But you have used Crystal Reports yourself (right?), so you
probably already know much more about it.

Jan

Am Mi, den 29.10.2003 schrieb Jason Cater um 15:40:
> As I've pointed out in IRC, I *really* wish we wouldn't move focus to
> GNUe Reports Server at this time.  I'm trying to get the GNUe Reports
> engine working well first. I think doing the reports server right now
> will just cause it to be redone when I finalize the reports engine
> interface. We have too many unfinished things as it is. 
> 
> >From your notes below, though, I do agree we'll need authentication. I
> personally don't like the idea of uploading report definitions via the
> server, though, and am not so sure about the async "feedback" thing. I
> think it's overkill at this stage. 
> 
> -- Jason 
> 
> 
> On Wed, 29 Oct 2003 12:39:42 +0100
> Jan Ischebeck <address@hidden> wrote:
> 
> > Hi,
> > 
> > yesterday I hacked a bit on the gnue-reports-server fragments, and
> > made it actual usable. By adding a sample php client implementation I
> > hope to increase the value of GNUe for Webapplications as the current
> > Arias.
> > 
> > By describing the current interface of the GNUe Reports Server I want
> > to show current design flaws, how I think these flaws could be
> > resolved and want to know what you all think about the stuff.
> > 
> > Implementation:
> > ===============
> > (as seen from client side)
> > 
> > GNUe Reports calls GNUe Reports Server in the following way:
> >     
> > ## PREPARATION
> > 
> > # 1. Server parameters are set
> > params = {'host': 'localhost', 'port': 8766, 'transport': 'http' }
> > interface = 'xmlrpc'
> > 
> > # 2. A gcomm interface is created from the settings
> > gcomm      = GComm.attach(interface, params)
> > 
> > # 3. A proxy object is created for the "GReportServer"
> > rep_server = gcomm.request("GReportServer")
> > 
> > ## RPC calls
> > 
> > # 4. get new report engine
> > rep_engine = rep_server.requestReportEngine()
> > 
> > # 5. set parameters
> > rep_engine.setDestination(destination, destinationType,
> > destinationOptions)
> > rep_engine.setFilter(filter, self.OPTIONS['filter_options'])
> > 
> > # 6. process the report
> > rep_engine.processReport(reportfile, userParameters,        
> >                          sortoption, self.OPTIONS["comment"],
> >                          self.OPTIONS["exclude_xml"])
> > 
> > # 7. remove the engine
> > rep_engine.clear()
> > 
> > TODO & COMMENTS:
> > ================
> > 
> > 1. Implement a way to store settings for both server and reports
> > client
> > 
> > * how should the rpc connection parameters for the report server be
> > stored? (Step 1)
> >  
> > * what about the interface parameters of the server itself?
> > 
> > * do we need a seperate [gnue-reports-server] section in gnue.conf?
> > 
> > 2. Add security framework
> > 
> > * do we need a login procedure? (IMHO yes!, password etc. could be
> > passed to requestReportEngine)
> > 
> > * security checks for report names, output file names 
> > 
> > 3. Add asynchronous report processing
> > 
> > I thought of a "report" proxy class, which provides processing status
> > of the report. (needs new thread and synchronizing on server side)
> > Something like this:
> > 
> > report = rep_engine.buildReport(....)
> > 
> > report.start_processing()
> > 
> > while not ready:
> >    ready = report.Status()
> >    // do other stuff
> >    sleep(x)
> > 
> > print(report.fetchResult())
> > 
> > 4. Add report uploading/result downloading in the report server
> > itself.
> > 
> > uploading: IMHO not directly needed and a security flaw in some parts.
> > result downloading: could be usefull for html reports 
> > 
> > 
> > Please read critical and comment.
> > 
> > Jan
> > 
> > 
> > -- 
> > Jan Ischebeck <address@hidden>
> > 
> > 
> > 
> > _______________________________________________
> > Gnue-dev mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gnue-dev
> > 
> 
> 
> _______________________________________________
> Gnue-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue-dev
-- 
Jan Ischebeck <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]