Re: Global Namespaces

[John Locke <..hidden..>]

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.

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 <..hidden..>
To: Development discussion for LedgerSMB
<..hidden..>
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 <..hidden..>
>> To: Development discussion for LedgerSMB
>> <..hidden..>
>> 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&#174; 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
>>> ..hidden..
>>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>>>
>>>       
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>> ..hidden..
>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>>
>>     
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>