On 1/29/07, William Hamilton <[EMAIL PROTECTED]> wrote:
> Chris Travers wrote:
>
> > This certainly has come up in the past. I am not sure we have a
> > complete idea of how this is going to work yet. I think we want to
> > get more of our own infrastructure developed and tested before opening
>
Chris Travers wrote:
> This certainly has come up in the past. I am not sure we have a
> complete idea of how this is going to work yet. I think we want to
> get more of our own infrastructure developed and tested before opening
> it up to other sub-projects, however. I suspect that the next st
--- Chris Travers <[EMAIL PROTECTED]> wrote:
> After thinking a great deal about Josh Berkus's suggestion that we use
> a text file with some sort of self-documenting API capabilities.
Did that mean the documentation of the 90% stored procedure API, or the
automation API of the 10% layer in perl?
Hi Ed;
Not sure if you are aware that we are looking at some experimental (?)
REST support in 1.3.
My post was about the application to database API. If we have an
intelligent database which contains its own object method to
relational procedure mappings, then it means that anyone who wants to
w
--- Chris Travers <[EMAIL PROTECTED]> wrote:
> > I think this would be an appropriate time to ask a question I've been
> > holding: will the core LedgerSMB developers weigh in on what types of
> > LedgerSMB-related projects they would consider allowing to use the (or a)
> > repository on the eventu
> Any ideas or feedback?
>
I haven't implemented it on a real project yet, but I like the look of
the REST approach (over say, SOAP or xmlrpc).
It's simple, and yet it follows the same structure as the main
application, so really all you are doing is saying that people can post
a given fo
Hi;
After thinking a great deal about Josh Berkus's suggestion that we use
a text file with some sort of self-documenting API capabilities. In
general, I like this idea, but I was wondering if it was a good idea
to store this in the database. If we want to, we could also use
something like XML o
--- Chris Travers <[EMAIL PROTECTED]> wrote:
> > I would think that as long as a module's functionality has any possibility
> > of being integrated with, or some code moved to, the LedgerSMB core, then
> > the code base benefits by keeping that development process close to home.
>
> Not quite sure
On 1/29/07, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote:
> Jeff Gerritsen wrote:
> > I'm thinking about creating a sourceforge project to post the
> > information to and allowing for others comments?
>
> I think this would be an appropriate time to ask a question I've been
> holding: will the core Led
Jeff Gerritsen wrote:
> I'm thinking about creating a sourceforge project to post the
> information to and allowing for others comments?
I think this would be an appropriate time to ask a question I've been
holding: will the core LedgerSMB developers weigh in on what types of
LedgerSMB-related pro
Thanks for your input Darald,
I'll keep the list informed of developments. I'm working on a detailed design
document and planning on posting more detail later this week. Hopefully the
document will give the specific detail your seeking. If it doesn't feel free
to let me know any additional de
My comments below.
Jeff
On Saturday 27 January 2007 11:10, Chris Travers wrote:
> As I think about it, I do have at least one customer that might be
> interested in some of this down the road. They currently use
> SQL-Ledger 2.4 in a limited point of sale capacity, and we are trying
> to move th
Charley,
Thanks for the input.
I've found some manufacturing documentation published on the web and I'm
sifting through the material to develop commonalities to be used in
developing a design plan or design document for review.
I'm thinking about creating a sourceforge project to post the inf
13 matches
Mail list logo