[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Evaluating Catalyst and other frameworks
- Subject: Re: Evaluating Catalyst and other frameworks
- From: Chris Travers <..hidden..>
- Date: Wed, 17 Mar 2010 13:11:53 -0800
On Wed, Mar 17, 2010 at 11:53 AM, Alejandro Imass <..hidden..> wrote:
> On Wed, Mar 17, 2010 at 3:05 PM, Chris Travers <..hidden..> wrote:
>> On Wed, Mar 17, 2010 at 3:45 AM, Ed W <..hidden..> wrote:
>>> On 09/03/2010 21:11, Chris Travers wrote:
>>>> Hi all;
>>>>
>>>> I have spent some time looking at Catalyst to see what would be
>>>> required to make LedgerSMB run according to current development
>>>> approaches (close to the db, etc) and the result isn't easy.
>>>> Basically, at a minimum, the following would need to be ported:
>>>>
> [...]
>
>
>> Similarly, regarding sessions, these are not just flat representations
>> of application session data. These are fairly complex objects which
>> interface with the web application and database in a variety of ways.
>> Disclosure of session data is security critical and so it is one of
>> the few tables which will probably long-term be "security-definer
>> only" for access.
>>
>
> I take it from lack of response to my previous post that there is no
> current consideration opf p2ee a base for a ne LSMB?
Actually I have been thinking about it a lot :-), but forgot to
respond.... I will respond tonight in a separate email.
> Anyway, regarding sessions, they are a beast created by using HTTP as
> a transport protocol instead of what it was designed for: a transfer
> protocol. In the p2ee framework we don't have a need for sessions are
> everything is a resource that is self represented, in other words we
> are purely REST. There are 3 types of resources: Application, Business
> Element Resources (BER), and Business Process Resources. And, most
> importantly, it's not just a wanna be concept, I have real working
> apps, although they are alpha and none in production yet. Please let
> me know if you want to explore this further.
In 1.3, we use sessions for two things:
1) flow control over long, non-concurrent-safe workflows (batch
payment being the major example). Basically we used them to lock a
set of records from other similar workflows. When the session times
out, the locks go away (preventing a lot of stale lock issues).
2) Anti-xsrf controls. All forms are tied to a session cookie so you
have to have both the cookie value and the form id to be able to post
to the db.
The first one would also be applicable to a non-web-based environment
because someone could lock the records in such a way that only the
conflicting workflows would worry about them, and one can easily
determine who locked the record in case this is a problem and you need
to go talk to him/her. The second could be implemented differently
without sessions per se, but since we have to use sessions anyway,
they are connected there. A side effect means that they too time out
only when the session times out.
Hope this helps,
Chris Travers
>
> Best,
> Alejandro Imass
>
>> I don't think this would be too bad to port (would probably be the
>> easiest of the three areas).....
>>
>> 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
>> ..hidden..
>> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>