Rename django-timelog so that the name is not tied to Django

ICT-Infer / timelog

Time sheet time tracking

ISC License

1 stars 0 forks source link

Rename django-timelog so that the name is not tied to Django #62

Closed yarwelp closed 9 years ago

yarwelp commented 9 years ago

New name: timelog-core.

yarwelp commented 9 years ago

Have timelog-core be shared code and database stuff and split off timelog-http for web stuff?

yarwelp commented 9 years ago

But probably the api should be part of core, so then timelog-http is a poor name unless one went with splitting out timelog-api-http and timelog-ui-http. Would that be taking it too far? It might.

yarwelp commented 9 years ago

Why not timelog-server-api-http and timelog-client-ui-http even.

yarwelp commented 9 years ago

Server-to-server communication could still happen so those names don't lock us in much in terms of future flexibility either.

yarwelp commented 9 years ago

But then, if we want to share code between server and web client, does that mean... Node.js?

yarwelp commented 9 years ago

I don't want to do Node.js for this. Maybe for something else in the future. How about Clojure? I'm not actively looking to switch. I like Python. I'm not even sure there's need for much shared code anyways.

yarwelp commented 9 years ago

Re: Clojure. ClojureScript comprises more than a subset of Clojure according to https://www.paren.com/posts/isomorphic-clojure-part-2-portable-code, making code sharing out of the question for now. Even so, for the client, Om (ClojureScript wrapper for React) seems interesting. In his JavaOne 2014 talk Clojure, Made Simple, which I watched just yesterday, I believe Rick Hickey (inventor of Clojure) claimed that Om, due to its immutability-properties, could outperform React(!) Now, he also said that the Facebook guys were interested in making optimizations to React based on the approach taken by Om, so it remains to be seen whether this claim will remain true but still, Om is worth investigating.

yarwelp commented 9 years ago

EuroClojure 2015 talk Om Next by David Nolen highlights some problems with REST in rich client-side applications. Mentions Netflix JSONGraph/Falcor and Datomic Pull Syntax and how Falcor and Datomic Pull Syntax has inspired Om Next.

Falcor routes data structure keys to microservices on the client. Om Next will not include a router itself. The shape of the thing returned is precisely the shape of the thing requested.
Datomic Pull Syntax describes in a declarative way what you need.

Om Next is not yet ready.

Integration with Datomic. [Compelling, sure, but Datomic is proprietary.]

No coordination between server and client.

More was talked about as well.

yarwelp commented 9 years ago

http://rauchg.com/2015/pure-ui/

yarwelp commented 9 years ago

Real Time Web Apps with (just) Python and Postgres (starting at 7m30s, skipping the why and straight to the how).

yarwelp commented 9 years ago

http://falconframework.org/