On Sat, 13 Mar 2010, John Locke wrote: > I do think being able to accommodate XML is a necessity, especially for > integrating with all of the other systems that use that as a medium.
I started to write my own back on SL, because of the need to handle EDI transactions. Fortunately, that project got canned (the client had an emergency and went out of business, unfortunately, never requesting their downpayment back). > However, put me in the JSON camp for actual new application > development--far less wordy, a lot quicker in browser-based application, > and just as easy to parse/widespread library support. > > I think we need to be able to handle both -- at least speaking as > someone who does a lot of integration work. > > Cheers, > John > > -------- Original Message -------- > Subject: Re: [Ledger-smb-devel] Global Namespaces > From: Luke <[email protected]> > To: Development discussion for LedgerSMB > <[email protected]> > Date: Sat 13 Mar 2010 11:56:08 AM PST >> I was thinking yesterday, that it would be nice to have an entire XML >> based interface. If most of the system was a backend which handled XML >> documents, the frontend could be a web app, a thick client, or any other >> sort of thing--the backend would have no reason to care. >> >> All a new module would have to do, is process the portion of XML data >> passed to it by ID, and the frontend would consist of the UI section >> relating to that module, and a formatter to post the proper XML. >> >> I realize that could get tricky with thick clients, but probably on the >> read side more than the write side. >> >> Just musing. >> >> Luke >> >> On Sat, 13 Mar >> 2010, John Locke wrote: >> >> >>> Just reading back through the architecture threads, and I think it all >>> mostly sounds great, I like the direction you're going. >>> >>> One thing comes to mind: I don't see a way of detecting in the Request >>> struct the difference between a query argument in the URL vs the body, >>> e.g. GET vs. POST parameters. >>> >>> Are these going to get munged together? I do sometimes find it useful to >>> distinguish between the two, especially if the body contains something >>> other than a query string format (e.g. JSON, XML). As I'm doing more and >>> more resource-based web services, it seems like the Request struct may >>> need some more detail: >>> >>> >>>> struct LedgerSMB::Web::Request, { >>>> params => '*%', # formerly top-level hash >>>> method => '$', # GET/PUT/POST >>>> headers => '*%', # Defined for the interface >>>> url => '$', # full url requested >>>> script_nsp => '$', # namespace of the script to run >>>> dispatch_point => '$', # formerly 'action' on the top-level >>>> }; >>>> >>>> >>> I'm thinking that for easy integration, it would be nice to be able to >>> create a handler plug-in to translate some generic POST data into a >>> standardized document/struct of some kind that the rest of LSMB can >>> recognize. Not sure this needs to be a global, but it's something I >>> could see needing to do. >>> >>> Basically, I'd want to be able to parse the GET arguments, and translate >>> the payload from a JSON- or XML- formated document into params that >>> regular LSMB modules can handle. I'd want access to the raw payload, and >>> to know how to populate the Request struct appropriately. So perhaps add: >>> >>> get_params => '*%', >>> raw_post => '$', # only populated on POST/PUT >>> >>> ... and specify that 'params' by default contains the get_params merged >>> with a parsed query-string from the raw post (with POST variables >>> overriding GET variables on collision). raw_post might be a query >>> string, an XML document, a JSON document, binary data, or whatever other >>> format a plug-in handler can interpret. >>> >>> Then my handlers can modify the params after parsing the raw_post, >>> translate it into something that the rest of LSMB can process. >>> >>> >>> Is this kind of feedback useful? >>> >>> Cheers, >>> John >>> >>> >>> >>> >>> -------- Original Message -------- >>> Subject: [Ledger-smb-devel] Global Namespaces >>> From: Chris Travers <[email protected]> >>> To: Development discussion for LedgerSMB >>> <[email protected]> >>> Date: Sat 13 Mar 2010 11:00:01 AM PST >>> >>>> I am thinking of suggesting two global namespaces >>>> >>>> In package LedgerSMB >>>> >>>> use Class::Struct LedgerSMB::Globals => { >>>> user => 'LedgerSMB::User', >>>> session => 'LedgerSMB::Session', >>>> config => 'LedgerSMB::ConfigFile', >>>> # Config settings, similar to Sysconfig today >>>> }; >>>> >>>> our Globals = LedgerSMB::Globals->new(); >>>> >>>> in pacakge LedgerSMB::Web: >>>> use Class::Struct LedgerSMB::Web::Globals => { >>>> session => 'LedgerSMB::Session::Web', >>>> request => 'LedgerSMB::Web::Request', >>>> }; >>>> >>>> our Globals = LedgerSMB::Web::Globals->new(); >>>> >>>> Any other globally accessible information that needs to be available >>>> globally through apps/scripts? >>>> >>>> Best Wishes, >>>> Chris Travers >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Ledger-smb-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Ledger-smb-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Ledger-smb-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel >> > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > I know absolutely nothing about it. Luke ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
