ProfileService Specification

From MacroDeckDevWiki

This is a draft document. It may change at any time.

ProfileService will provide profile support to MacroDeck and to applications that implement MacroDeck Services. It will be built on top of DataService. Profile items can be group-specific (for example, normal people might not care what my favorite type of grass is, but people in my grass lovers group would), so they only show up by default to viewers who are members of a particular group. Lists will themselves be data groups (and their children data items) whose parent is the profile data item. So, if I were to have a favorite movies list, the tree might look like this:

 + Profile: ZiggyTheHamster
 |--+ Favorite Movies
 |  |-- Back to the Future
 |  |-- Back to the Future II
 |  |-- Back to the Future III
 |  |-- Super Mario Bros.
 |  |-- Short Circuit
 . . .
 |  |-- Little Nicky
 |-- Name: Keith Gable
 |-- Age: 18

Name, Age, and Favorite Movies will be data items. Name will simply store my name as the data item's stringdata. Age will do the same with my age in integerdata. There will also be a "Favorite Movies" data group, whose parent is set to the Favorite Movies data item.

ProfileService should always check to see if a list exists for a particular item (look for a DataGroup whose parent is the DataItem/profile item you're parsing), even if it doesn't actually make sense (age, name, etc.).

Care should be exercised to make sure that you get data items with no parent (i.e. they're root nodes). So WHERE parent = NULL is sufficient (there's actually a function to do this in DataService).

Contents 1 Features Exposed To Ruby 2 Features Exposed Via XML-RPC/SOAP 3 Widget-Specific Features 4 Application-Specific Features 5 Synchronizable Data 6 Interaction With Other Services 7 Technical Data 7.1 UUIDs 7.2 APIs 7.3 Front End

Features Exposed To Ruby

• Add/get/delete/edit profile items (implemented as data items)
• Add/get/delete/edit profiles (implemented as data groups) .. this will be done on registration, but the function needs to be there.
• Find relevant profile items. Currently, this means: show less to strangers, show more to friends, and profile items which are group or interest-specific should be shown to people who care.
• Get profiles for users/groups

Features Exposed Via XML-RPC/SOAP

• Add/delete/edit profile items
• Get profiles for users/groups (should be the same result as the controller would give)

Widget-Specific Features

• Get profile items (I can't think of anything else a widget might want to grab if the profile page already exists)

Application-Specific Features

This service is designed to be functionally similar on applications outside of MacroDeck as well as widgets on MacroDeck.

Synchronizable Data

• Profiles (per-user/group)
• Profile items (per profile)

Interaction With Other Services

• UserService will be used for determining context when displaying profiles
• UserService will be used for permission verification
• UserService will be used for access control
• DataService will be used for data storage

Technical Data

UUIDs

• 065479a8-d2da-4e39-881a-ada619b1a252 - Profile field (DataItem datatype)
• bf1d3af2-3437-489f-9f09-24151edeb827 - User/group's profile (DataGroup datatype)

APIs

No APIs are currently defined.

Front End

The official MacroDeck front end should be a controller (ProfileController) that should be accessed at /user/name/profile, and the same for /group. Access controls should be applied obviously. Since profiles are implemented as data items, this is mostly done already.