Last Week:
The database ended up in a much different (and significantly pared down) form than I had anticipated. Instead of the multitude of node wrappers that I had last week (one for each kind of object in the database), now there is only one kind, and nodes are distinguished between based on relationships. For instance, all "People" nodes are connected to the "People" subreference node. For clarity, here is a picture:
Subreference nodes are in blue, the reference node (database entry point) is green. Relationships are labeled in all caps. This is mostly an implementation issue, but I thought I would touch on it. Having lots of different node types (Plain Old Java Objects wrapping the underlying nodes) is only useful if they are each storing lots of different information. Because as planned, mine weren't (I brought most of the properties out to make them into nodes), it made more sense to kill the proliferation of wrapper nodes. It certainly cleaned up the implementation a lot.
All right, so that is up at http://code.google.com/p/hackystat-analysis-socnet/
It's shiny and commented, too.
The Server
Also this week, the Server work began. I watched the screencast on the design of the sensorbase, and the one on building it from sources...
I built the Sensorbase from source this week. This was actually very easy and pleasant. (I was pleasantly surprised!) Yay, Ivy integration! There was an issue with JavaMail and JAXB, but that was ironed out very easily. JavaMail only comes with Java 6 Enterprise Edition, or something like that.
I edited the SensorBase code so that when you ping it, it responds with a Hello World. This did not require much change, actually--I just removed a lot of code from the Server class, added a HelloPing resource, and borrowed code from the Client class to test and make sure it was working. I will put the changed code up on my google project page, though it's not terribly exciting.
Now, Philip says that developing an API really informs the design of a server, so I have the first draft of that. I based it somewhat off the Sensorbase API. I would very much appreciate feedback on the API. I think I hit on most of what was needed, but could totally have left things out. This will go in my google project's wiki as soon as I learn wiki markup for tables. Currently, it's in the downloads section.
| GET | {host}/nodetypes | Returns a list of all of the node types in the graph |
| GET | {host}/nodetypes/{nodetypename} | Returns a representation of the named node type |
| PUT | {host}/nodetypes/{nodetypename} | Create a representation of the named node type (admin) |
| DELETE | {host}/nodetypes/{nodetypename} | Delete the named node type (admin) |
| GET | {host}/relationshiptypes | Returns a list of all the relationship types in the graph |
| GET | {host}/relationshiptypes/{relationshiptypename} | Returns a representation of the named relationship |
| PUT | {host}/relationshiptypes/{relationshiptypename} | Create a representation of the named relationship type (admin) |
| DELETE | {host}/relationshiptypes/{relationshiptypename} | Delete the named relationship type (admin) |
| GET | {host}/clients | Returns a list of all of the clients using the server |
| PUT | {host}/clients/{client} | Returns a representation of the named client |
| POST | {host}/clients/{client} | Updates the representation of the named client |
| DELETE | {host}/clients/{client} | Deletes the named client |
| GET | {host}/nodes | Returns a list of all the nodes in the graph |
| GET | {host}/nodes/{nodetype} | Returns a list of all the nodes of that type in the graph |
| GET | {host}/nodes/{node}/ | Returns a list of all of the nodes connected to the named node |
| GET | {host}/nodes/{node}/{relationshiptype}/{relationshipdirection} | Returns a list of all of the nodes connected to that node by the specified relationship and relationship direction |
| GET | {host}/nodes/{node}/{nodetype} | Returns a list of all of the nodes of the specified type that are connected to the named node |
| GET | {host}/nodes/{node}/{relationshiptype}/{relationshipdirection}/nodes?startTime={tstamp}&endTime={tstamp} | Returns a list of all nodes that were connected to the named node by the specified relationship and relationship direction during the specified time period |
| GET | {host}/nodes/{node}/{nodetype}/nodes?startTime={tstamp}&endTime={tstamp} | Returns a list of all of the nodes of the specified type that were connected to the named node by a relationship between the start time and the end time |
| GET | {host}/nodes/{node}/relationships?startTime={tstamp}&endTime={tstamp} | Returns a list of all of the relationships that were connected to the named node during the specified time interval |
| PUT | {host}/nodes/{node} | Creates a representation of the named node |
| POST | {host}/nodes/{node} | Updates the representation of the named node |
| DELETE | {host}/nodes/{node} | Delete the named node |
| GET | {host}/people | Returns a list of all of the people nodes in the graph |
| GET | {host}/people/users | Returns a list of all of the people nodes in the graph who are users of the system (ie, those who have added the facebook/twitter apps and are submitting data |
| GET | {host}/people/nonusers | Returns a list of all of the people nodes in the graph who are not users of the system (ie, those that are, for instance, friends of users, but are not users themselves.) |
| GET | {host}/people/users/{user} | Returns a representation of the named user |
| PUT | {host}/people/users/{user} | Creates a representation of the named user (admin) |
| POST | {host}/people/users/{user} | Updates the representation of the named user |
| DELETE | {host}/people/users/{user} | Deletes the named user |
| GET | {host}/people/nonusers/{nonuser} | Returns a representation of the named nonuser |
| PUT | {host}/people/nonusers/{nonuser} | Creates a representation of the named nonuser (admin) |
| POST | {host}/people/nonusers/{nonuser} | Updates the representation of the named nonuser |
| DELETE | {host}/people/nonusers/{nonuser} | Deletes the named nonuser |
This Coming Week:
The SocNet Server is top priority. I will be modeling it after the Sensorbase, with a couple of changes. I intend for resources to be loaded from a config file, for one.
Authentication is somewhat of an issue: each client sending data will have a username and password, but what about getting data? There is no simple way for me to ensure that a user who has added the facebook app is the same one who is requesting data. So that is currently an issue that I am not sure how to resolve.
To get a better idea of what I am talking about, here is another picture:
The issue is that there is (currently) no overarching user registration plan. Perhaps such a thing should be added.
0 comments:
Post a Comment