Now I know this is putting the cart before the horse here, but the recent discussions about the online store made me consider what further features we could provide on the pandora.
Basic social networking
From the mock ups / screenshots I have seen of the store, it seems as if it is going to require the user to log in, but what if we treat the login to the store as a federated identity.
numerous standards exist that could make it very useful, PRIMARILY openid but also oauth.
Tie that into LDAP on the backend, and feed that into an XMPP server (although i'm so used to using google for jabber these days), and you have
1) a pandora ID
2) A friend list
3) a chat mechanism
4) an incredibly useful routing mechanism for any kind of messages.
There are numerous libraries to speak to jabber servers, and the nice thing is you can build it so it queues messages locally (you don't have to be online
all the time, it can just poll and fetch).
The XMPP connection alone would make it possible to implement some turn based homebrew such as chess or go.
More advanced/invasive features
One of the biggest features of the console networks is how directly they are tied into the games themselves. So, to properly implement this would
mean that we would actually need to modify the source code of the emulators / games, and provide a "pandora-lib" of sorts, that implements
some standard features across all pandora apps.
Think of it as a more in-depth emulator front end, which at first could be as simple as setting the status of 'I am playing X game on Y emulator',
which also opens up the question of privacy settings.
This library should also be able to be used in homebrew games that have been written / ported to the pandora, and all the games on the store
that have been "pandora-enabled" could be flagged as such on the store.
I do not see applications needing to be implemented with this functionality. who cares if "i am using a word processor" or more shockingly
"i am browsing sexwithhippos.com". :rolleyes:
As the API evolves it could start providing features such as an emulator front end would (ie: a stock rom picker, a standard pause screen, access
to network features)
Really not expecting major things to be able to be done overnight, especially because we need to actually have the emulators ported first
to be able to see if the standard lib idea is even possible.
match making
Next part is match making, for which the OBVIOUS option is kalliera. However, it is closed source and very near dying.
Server-Client is not the best way to handle this either imo. If we do choose to implement kalliera (as in, if it's even possible),
there exists an open source implementation of the server component - http://www.emulinker.org/
What I think would be more interesting and way trickier, is seeing if we can get the people behind open kalliera to get involved.
They started as an open source re-implementation of kalliera, and then fizzled out 2 years ago,but it seems they recently
resurrected with some pretty lofty goals. http://sourceforge.net/projects/okai/
You can see their spec document here (http://okai.svn.sourceforge.net/viewvc/okai/trunk/docs/system-definition.tex?revision=78&view=markup)
Just parse out the tex
What could even be an interesting thing to try and do, is write a dummy USB device, which is actually the network input. Pretending to be usb HID.
in closing
yes this is a 1000ft overview of the idea, yes it's not possible to implement this stuff properly yet .. but a guy can dream =P
what other uses can you see for a pandora live / pandora network type system, and more interestingly .. what do you think a 'pandora-lib'
api should provide.
Something the pandora has that a lot of other situations don't is a small, loyal and fairly technical user base.
Basic social networking
From the mock ups / screenshots I have seen of the store, it seems as if it is going to require the user to log in, but what if we treat the login to the store as a federated identity.
numerous standards exist that could make it very useful, PRIMARILY openid but also oauth.
Tie that into LDAP on the backend, and feed that into an XMPP server (although i'm so used to using google for jabber these days), and you have
1) a pandora ID
2) A friend list
3) a chat mechanism
4) an incredibly useful routing mechanism for any kind of messages.
There are numerous libraries to speak to jabber servers, and the nice thing is you can build it so it queues messages locally (you don't have to be online
all the time, it can just poll and fetch).
The XMPP connection alone would make it possible to implement some turn based homebrew such as chess or go.
More advanced/invasive features
One of the biggest features of the console networks is how directly they are tied into the games themselves. So, to properly implement this would
mean that we would actually need to modify the source code of the emulators / games, and provide a "pandora-lib" of sorts, that implements
some standard features across all pandora apps.
Think of it as a more in-depth emulator front end, which at first could be as simple as setting the status of 'I am playing X game on Y emulator',
which also opens up the question of privacy settings.
This library should also be able to be used in homebrew games that have been written / ported to the pandora, and all the games on the store
that have been "pandora-enabled" could be flagged as such on the store.
I do not see applications needing to be implemented with this functionality. who cares if "i am using a word processor" or more shockingly
"i am browsing sexwithhippos.com". :rolleyes:
As the API evolves it could start providing features such as an emulator front end would (ie: a stock rom picker, a standard pause screen, access
to network features)
Really not expecting major things to be able to be done overnight, especially because we need to actually have the emulators ported first
to be able to see if the standard lib idea is even possible.
match making
Next part is match making, for which the OBVIOUS option is kalliera. However, it is closed source and very near dying.
Server-Client is not the best way to handle this either imo. If we do choose to implement kalliera (as in, if it's even possible),
there exists an open source implementation of the server component - http://www.emulinker.org/
What I think would be more interesting and way trickier, is seeing if we can get the people behind open kalliera to get involved.
They started as an open source re-implementation of kalliera, and then fizzled out 2 years ago,but it seems they recently
resurrected with some pretty lofty goals. http://sourceforge.net/projects/okai/
You can see their spec document here (http://okai.svn.sourceforge.net/viewvc/okai/trunk/docs/system-definition.tex?revision=78&view=markup)
Just parse out the tex
What could even be an interesting thing to try and do, is write a dummy USB device, which is actually the network input. Pretending to be usb HID.
in closing
yes this is a 1000ft overview of the idea, yes it's not possible to implement this stuff properly yet .. but a guy can dream =P
what other uses can you see for a pandora live / pandora network type system, and more interestingly .. what do you think a 'pandora-lib'
api should provide.
Something the pandora has that a lot of other situations don't is a small, loyal and fairly technical user base.
