Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Code structure #2

mplorentz opened this Issue Apr 10, 2013 · 14 comments


None yet
4 participants

mplorentz commented Apr 10, 2013

I've never used Flask before, so I'm not sure what the usual structure is. It seems to me though that for smoke signals we'll need a Entity model/view/controller, which will be linked to our single database table. Then we need a daemon that will go through each entity and fetch/post every X minutes

Is python's built-in support for threads going to be sufficient? I haven't ever used them.

Am I missing anything?


bnjbvr commented Apr 10, 2013

I'm OK with the MVC structure. Somebody talked about a sqlite database and I really think that may be a good idea (not in term of performance, but awesome in term of ease to deploy on your host server).

We should clearly separate 2 differents processes:

  • one is the webserver, anyone can subscribe and manage its subscriptions.
  • the other one is the go fetch / send to user part.

As the second one needs information that could be retrieved by the first one, both could communicate either via any IPC form or a Redis store (which IS definitely efficient).

I read that Python threads were to avoid (can't remember the arguments though).

Should it absolutely be written in Python? My current demo app is written in Javascript (CoffeeScript, which is actually more like Python than js)


seanmonstar commented Apr 10, 2013

I'd stay away from threads. There is no need. The webserver will be one process, and fetching the feeds can be a different process started from cron.

Is there a decent feed parsing library in nodejs?


bnjbvr commented Apr 10, 2013

The one I am using, feed-parser, is working and seems still updated:

Moreover, it creates guid when it doesn't find any (using the link as uniqueness criteria).


mplorentz commented Apr 11, 2013

Would you guys rather implement it in javascript? I think @florianjacob was willing to help if it was in nodejs.

If you do, which I would be completely fine with, I'd want one of you to host the repo, because I've never used nodejs or coffeescript. I'll still do my best to contribute though.


seanmonstar commented Apr 11, 2013

I know node fairly well. It's what I write at work. And I used to write
Python, so either way.

Not to start a war over CoffeeScript, I think it's perfectly fine to use in
a personal project, but I'm not convinced it should be used in an open
source project where we hope people will contribute...


florianjacob commented Apr 11, 2013

@mplorentz no, it's the other way around. ;)

Sean McArthur
^bnj.tent.is I've been trying to see if we can get a bridge for v0.3. Would you want to contribute the start you have? We can switch to node.js :-)

Florian Jacob
^mattl I don't know whether I'll be of any use in case you switch to a node.js implementation, but why not? ;)

Did I do something wrong with the double negative? xD
What I meant was that I have no node.js experience at all, the only javascript I ever did was simple website stuff. So if we do it with node.js, I'll still do my best to contribute, like you, but that won't be much until I know more about that stuff.

Python is my favourite scripting language, and I already worked with flask for web apps.

Can't say anything to CoffeScript, but at least it looks more elegant than plain javascript. ;) And it feels like it's widely used, I don't think we would loose much contribution through that.


bnjbvr commented Apr 11, 2013

I disagree that CoffeeScript shouldn't be used for large projects. CoffeeScript is now mature, and even has a simple way for debugging, which is the recently implemented SourceMaps (useful at least for client debugging).
Dropbox (https://tech.dropbox.com/2012/09/dropbox-dives-into-coffeescript/) is an example that it can be adopted for large, real-world production website :)

However, I am not bound to any langage, so if you prefer Javascript, or Typescript, or Brainfuck, or Awk, it is no problem for me.

Actually, webserver and backend processes could even be written in two different langages, so as to attract more people. In this case, I would advise to use javascript (or derived) for the web site (there is not a lot to implement) and python for the backend fetch RSS process (the feed parser you talked about seems more mature than node-feedparser).


seanmonstar commented Apr 11, 2013

If more people want to use CoffeeScript, then sure. Go for it. I still believe my original statement, but at the end, I just want a freaking Tent-RSS bridge :)


mplorentz commented Apr 12, 2013

Well it sounds like we're all ok or more comfortable with Python. While we may get more contribution if we did the front end in CoffeeScript, that would be one more dependency for users that wanted to self-host this app, especially on a low-power system like a Raspberry Pi. For those reasons I think we should keep it all in Python.


mplorentz commented Apr 12, 2013

Oh, I just now saw Sean's status post to Ben. If Ben already has something working, then we can definitely use that. Someone could always port it to Python if a lot of people want that.


seanmonstar commented Apr 17, 2013

Since no has said otherwise, and even @benjbouv suggested using Python on the server, I'm going to start working on some Flask pieces


seanmonstar commented Apr 18, 2013

I pushed up some super basic code that will run a flask app, and has a /feed?url= route that will fetch and output json of the feed.

I'd like to add issues of the things that are needed, and those that think they can handle that task, assign it to themselves.


mplorentz commented Apr 22, 2013

That sounds like a good plan. Maybe one issue for the models (user, feed, feeditem), one for the daemon, one for controller/view flow?


seanmonstar commented Apr 22, 2013

Sure, make issues for parts that make sense.

@mplorentz mplorentz closed this Jul 9, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment