Node client app

21 views
Skip to first unread message

Jeremy Kahn

unread,
Aug 13, 2012, 11:23:35 AM8/13/12
to pine-d...@googlegroups.com
While I still have a full plate with building out the UI, we should start thinking about the Node client portion of the app.  It will need to do a number of things, the first of which is serving static files.  I'm happy to drive the development of the Node client.  However, I have very little experience with developing in Node, so that may not to be the most efficient way forward.  That being said, would anyone else like to lead the Node client effort?  If nothing else, I'd like to discuss how it should be architected and what libraries we should consider.

I know that Luke and Alex are working on the ecosystem, but I'm not sure if that will involve developing the Node client at all.

Alex Wilson

unread,
Aug 13, 2012, 12:32:04 PM8/13/12
to pine-d...@googlegroups.com
I can work on the Node client. That will involve implementing the ecosystem's APIs and such, so I've already started a bit on that. I can start working on the static file serving, websocket communication, and the code needed to later implement the Pine API.

Scott Elcomb

unread,
Aug 13, 2012, 12:39:23 PM8/13/12
to pine-d...@googlegroups.com
I'll post updates to the distro & gamepad API threads shortly -
should've posted last night: I added a simple static webserver in the
auto-pine setup. I put it in to try some simple tests on hardware,
but is not meant to be permanent. (Probably want an express server
here.)

See <https://github.com/jeremyckahn/pine/tree/master/auto-pine/defaults/stage-2/home/pine-user>
- the server is pine.js with static files stored under the htdocs
folder.

--
Scott Elcomb
@psema4 on Twitter / Identi.ca / Github & more

Atomic OS: Self Contained Microsystems
http://code.google.com/p/atomos/

Member of the Pirate Party of Canada
http://www.pirateparty.ca/

Luke Stebner

unread,
Aug 13, 2012, 7:22:26 PM8/13/12
to pine-d...@googlegroups.com
Just a general recommendation to use express so that handling things like static vs dynamic pages and routes will be taken care of and the ability to use any middleware we end up needing for sockets and whatnot.

Jeremy Kahn

unread,
Aug 14, 2012, 12:56:52 AM8/14/12
to pine-d...@googlegroups.com
Express seems to be the popular choice, let's go with it. Alex, please made a directory in the Git repo for the Node app, it should probably be at the top level of the project.  From there we can fill in the basic dependencies and any npm bits we might need.

Scott, regarding directory structure, will having the Node client app in a top level directory interfere with how you've set up auto-pine?  Can we just symlink certain things together, or would that make everything too confusing?  Ideally I'd like to section off significant client components (like auto-pine, ui, the Node app) into top level directories so we can isolate them, but I don't know if that will make certain parts of the project difficult to work with.

If my directory structure suggestions are really wrong, please let me know.  I'm still learning the best practices for Node app development.

Alex Wilson

unread,
Aug 14, 2012, 1:47:16 AM8/14/12
to pine-d...@googlegroups.com
Where would files for the game be kept in the file system?

Jeremy Kahn

unread,
Aug 14, 2012, 8:37:22 AM8/14/12
to pine-d...@googlegroups.com
In production, the Pine files should live in various directories under $PINEUSER/home. For development, you can put them inside of the Node app directory and add them to the .gitignore file. 

--
Jeremy Kahn


Sent via mobile. 

On Aug 14, 2012, at 12:47 AM, Alex Wilson <arex...@gmail.com> wrote:

Where would files for the game be kept in the file system?

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/t1jzeYSXoqQJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Scott Elcomb

unread,
Aug 14, 2012, 9:15:36 AM8/14/12
to pine-d...@googlegroups.com
On Tue, Aug 14, 2012 at 12:56 AM, Jeremy Kahn <jerem...@gmail.com> wrote:
> Scott, regarding directory structure, will having the Node client app in a
> top level directory interfere with how you've set up auto-pine? Can we just
> symlink certain things together, or would that make everything too
> confusing? Ideally I'd like to section off significant client components
> (like auto-pine, ui, the Node app) into top level directories so we can
> isolate them, but I don't know if that will make certain parts of the
> project difficult to work with.

Top-level's good. I'll give auto-pine a pre-processing step to copy
the apps into defaults/stage-2/home/pine.

Best,

Alex Wilson

unread,
Aug 21, 2012, 12:23:24 AM8/21/12
to pine-d...@googlegroups.com
I haven't been able to get much done on the client app. I have some basic structure laid out, but I won't be able to have anything really worth committing until stuff like the API is finalized. I'll keep thinking about it, and I'll probably have something to show, even if it's just an example to guide future development.

Jeremy Kahn

unread,
Aug 21, 2012, 12:51:01 AM8/21/12
to pine-d...@googlegroups.com
Is there anything in particular slowing down?  If something is blocking you, let me know and I'll try to pitch in.

Rather than trying to commit one big swath of code at once, it may be helpful (and ultimately easier) to iterate and build out little chunks at a time.

On Mon, Aug 20, 2012 at 9:23 PM, Alex Wilson <arex...@gmail.com> wrote:
I haven't been able to get much done on the client app. I have some basic structure laid out, but I won't be able to have anything really worth committing until stuff like the API is finalized. I'll keep thinking about it, and I'll probably have something to show, even if it's just an example to guide future development.

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/yFlAm8sVbxwJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Scott Elcomb

unread,
Aug 25, 2012, 6:41:33 PM8/25/12
to pine-d...@googlegroups.com
Thanks for last nights commits Alex. Very much like what I was hoping for =D

Unfortunately, I've hit a snag with running mongod on the Pi. ;-(

There's no package in the raspbian repos and a quick search turned up
little information beyond others looking for help trying to build it.
Apparently it's possible to run v1.8 on the debian squeeze image using
the instructions at
<http://elsmorian.com/post/24395639198/building-mongodb-on-raspberry-pi>.
I'm hoping it'll just work on raspbian but some posts mentioned not
being able to get mongo to build. Also, when following the
instructions first-time through, I ran out of space before the
dependencies were even finished downloading from the apt repositories.
(QOTD: Why is xulrunner needed to build mongo?)

Anyway, going to modify the partitions in the base raspbian image and
try to free up some room. Until now we haven't had to do much with the
image beyond changing a few files; with mongodb, I'm starting think
we'll need to host a pine image sooner rather than later. (I can
offer a place to host it on psema4.com until we have a definitive
image and can seed a torrent, if necessary.)

Will follow up with progress a bit later.

Jeremy Kahn

unread,
Aug 25, 2012, 7:15:54 PM8/25/12
to pine-d...@googlegroups.com
Hmm, this certainly is a roadblock.  Assuming that we can't get get MongoDB to run as-is on Pine, we have two options:  Fix Mongo so it does work, or use something else.  I have no experience with Mongo, so I don't have much useful insight to offer in regard to fixing it.  However, I'm willing to dig in in order to help get it straightened out if you think that would help.

If worst comes to worst, can we consider a different type of DB, at least as a temporary solution?

Thanks for your research on this!

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

Scott Elcomb

unread,
Aug 26, 2012, 11:44:06 AM8/26/12
to pine-d...@googlegroups.com
On Sat, Aug 25, 2012 at 7:15 PM, Jeremy Kahn <jerem...@gmail.com> wrote:
> Hmm, this certainly is a roadblock. Assuming that we can't get get MongoDB
> to run as-is on Pine, we have two options: Fix Mongo so it does work, or
> use something else. I have no experience with Mongo, so I don't have much
> useful insight to offer in regard to fixing it. However, I'm willing to dig
> in in order to help get it straightened out if you think that would help.
>
> If worst comes to worst, can we consider a different type of DB, at least as
> a temporary solution?

Knowing what a powerful combination Mongoose + Express is, I'd really
prefer that. I'm not entirely certain, but we *might* be able to
replace some of the mongoose functionality with redis (which has a
package for raspbian) and nohm <https://github.com/maritz/nohm>.

Still compiling mongo... I have to head out for a few hours but I'll
send another update on mongo's status tonight.

Scott Elcomb

unread,
Aug 27, 2012, 12:47:00 PM8/27/12
to pine-d...@googlegroups.com
On Sun, Aug 26, 2012 at 11:44 AM, Scott Elcomb <pse...@gmail.com> wrote:
> On Sat, Aug 25, 2012 at 7:15 PM, Jeremy Kahn <jerem...@gmail.com> wrote:
>> Hmm, this certainly is a roadblock. Assuming that we can't get get MongoDB
>> to run as-is on Pine, we have two options: Fix Mongo so it does work, or
>> use something else. I have no experience with Mongo, so I don't have much
>> useful insight to offer in regard to fixing it. However, I'm willing to dig
>> in in order to help get it straightened out if you think that would help.
>>
>> If worst comes to worst, can we consider a different type of DB, at least as
>> a temporary solution?
>
> Knowing what a powerful combination Mongoose + Express is, I'd really
> prefer that. I'm not entirely certain, but we *might* be able to
> replace some of the mongoose functionality with redis (which has a
> package for raspbian) and nohm <https://github.com/maritz/nohm>.
>
> Still compiling mongo... I have to head out for a few hours but I'll
> send another update on mongo's status tonight.

Sorry for the late post. Compiling mongo unfortunately did not end
well. After a couple attempts and about 30 hours of compiling, I ran
into a brick wall. The issue is identified at
<http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=12582> and
concerns the building of spidermonkey.

Due to the amount of time required to compile, I won't be able to try
again until at least next weekend. :-( Really hate to say it but at
this point, it might be best to focus on a plan B.

More ORM possibilities in addition to redis + nohm: MySQL or Sqlite
with either Sequelize <http://www.sequelizejs.com/> or Node-Persist
<https://github.com/nearinfinity/node-persist>.

Alex Wilson

unread,
Aug 27, 2012, 2:47:32 PM8/27/12
to pine-d...@googlegroups.com
I like redis+nohm, but I can work with anything as long as it's the best fit for the project.

Jeremy Kahn

unread,
Aug 27, 2012, 10:36:07 PM8/27/12
to pine-d...@googlegroups.com
Due to the amount of time required to compile, I won't be able to try
again until at least next weekend.  :-(  Really hate to say it but at
this point, it might be best to focus on a plan B.

Dang.  Okay, thanks for working on this, I know it's really frustrating to spend a lot of time on something and not get the results you were hoping for.  The thread on raspberrypi.org looks promising, so I will keep an eye on it and hope for the best.  It doesn't make much sense right now to try and rip apart MongoDB, so let's look at solutions that work in the meantime.

It's my understanding that an ORM will allow us to swap one DB for another.  If we go with one type of DB now, we can easily(?) swap it out for another later, so this isn't the end of the world.

I'm not terribly knowledgeable on databases, but regardless of what we choose, we should go with the lightest solution possible.   What are our database requirements?  Given the DBs that are known to work, what is the least resource-intensive solution?  Scott, Alex and Luke, you know this stuff better than I, so I'd like to know what you think.

On Mon, Aug 27, 2012 at 11:47 AM, Alex Wilson <arex...@gmail.com> wrote:
I like redis+nohm, but I can work with anything as long as it's the best fit for the project.

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/IKdejx9vg4kJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Jeremy Kahn

unread,
Dec 2, 2012, 2:08:13 PM12/2/12
to pine-d...@googlegroups.com
Good news!  It looks like somebody managed to compile an ARM binary of MongoDB that works on the Raspberry Pi: https://github.com/brice-morin/ArduPi/tree/master/mongodb-rpi

Scott Elcomb

unread,
Dec 4, 2012, 12:35:34 PM12/4/12
to pine-d...@googlegroups.com
This is excellent news indeed; I'll be looking to include it in my
next build. I expect to have a few hours to put in this coming
weekend.
Reply all
Reply to author
Forward
0 new messages