Hacker Newsnew | comments | show | ask | jobs | submitlogin

"... Not just cut 'n' paste: cool mashup features like synchronization and single-point identity management (so you don't have to tell Facebook and Twitter what you're doing, you can just enter it in one place) ..."

I've been doing something similiar to this. Here's what I'm finding working with lots of different 3rd party sites ...

Using API's

- not every site has an API or RSS so you have to CUT+PASTE :(

- even sites with API's have poor documentation (code, txt) so it can be difficult to use

- posting data (say to twitter,flickr ) is way easier than extracting via an API/RSS

- no company(ies) want(s) their hard-won user data to be used commercially (check the legal agreements) so while you can integrate each site requires permission - yuk!

- solve the password & authorisation problem for each 3rd party site

Integration layer

- abstract an API to talk to each service (eg: as Perl does to databases in the DBI module)

- support the most popular sites that people use first (flickr, twitter, Facebook, MySpace etc)

- constrain the features you want to support for each 3rd party site (eg: notifications by friends in twitter, or flickr. New books suggested in http://www.librarything.com)

- keep up with changes made to each service, handle bugs, quirky code

Extraction layer

- synchronise 3rd party added data and client side added data (the "add in 1 place" bit mentioned). This means being able to either/or add data at the client or get the data the user added at the 3rd party site as well and somehow sychronise them

- you need tools to extract, manipulate RSS/ATOM feeds. A boon because you don't need API's

Messaging layer

- using your abstracted API be able to message various different services and here's the hard bit depending on the service. Do you want to send everyone on Twitter a photo update if you have entered 20 flickr photos?

- you need to capture store, query, link check and update the various links, metadata and information that message generates.

Presentation layer

- layering of data. Intelligent hierarchies of data that be queried by other

- flexible presentation layers that can export variety of data formats web pages as to XML, RSS files, mobile phone SMS, etc.

- flexible presentation layer(s) that can support different levels of information from a complete archive of past posts to their titles or individual tags

- metadata ... support things like tags, microformats at a per document level and be flexible enough to allow for more formats that arise.

Of course on top of this you have to build something that others will use, that is bug free as possible in Javascript. Something on or along the lines of Yahoo's YUI ~ http://developer.yahoo.com/yui/ Maybe this YUI or NewSDK is what Steve Yegge meant when he was talking about the "Next big language" ? ~ http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

In all this I can't help think that maybe just solving a few little problems might be a better starting point and if you do so make sure it's the open web and not some roach motel that sucks up data instead of allowing data to flow.




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: