>>>>> Tim Crews <tim-QJ3Fn9itRil4wfmgmkLWVgC/[email protected]> writes:
> This brings up some questions for the group: > 1. If the REST API relied on Python support, would that be a problem? Is > Python support expected to be exposed in the released version 3.0 > binaries, > or is the capability only meant for developers/tinkerers for the time > being? Not at all! In fact, I would prefer that it be in Python. > 2. Because ledger commands are primarily query-oriented, it is not too hard > to > imagine a straightforward mapping between the functions provided by the > Python API and RESTful queries. However, I know that some people get > passionate about REST design principles. Are there enough people who care > about such an API that we ought to have an up-front discussion about what > it would look like? Is this list the right forum for such a discussion? > Or should I just put something together and then publish it on my github > fork for discussion after the fact? This is the right forum for that discussion. > 3. Would Python library dependencies be problematic? I would probably use a > microframework like web.py to implement the REST server. I don't see such dependencies as problematic, as long as "pip" can install them and they don't get out of control. > 4. For my own purposes, I definitely want the capability to write back to the > ledger journal, i.e. there would be some PUT/POST verbs implemented. I > gather that this is contrary to the Ledger philosophy, but I'm not sure > about that. In the "Scaling Ledger" thread, John answered "Yep" when > asked > if we could *add*/remove data through the Python interface, but I'm not > sure what the scope of this answer was. I have not found any journal > writing code in the ledger source. Did I just miss it? You can manipulate the data structures in Python, but you'd have to write the whole file back out with a "print". However, this drops information. At the moment this is no way to perform an information-preserving transformation, since that has never been a feature of Ledger. > 5. John (if you're here), could you expand a little on "entirely in > Javascript"? I meant an Ajaxy UI that didn't need loads of server work to refreh data tables. But in reality it probably will require a spectrum of code on both sides of the divide. John
