[ecf-dev] Need advice for BBAPI refactoring

[Erkki Lindpere <erkki@xxxxxx>]

Hi!

I started looking at the bot framework to see how it could relate to my 
own bot code, then noticed that some of my code was broken due to the 
Presence API refactoring (great work BTW!) and started updating it. Now 
I ended up wanting to do some refactoring for BBAPI too, and maybe make 
it look more like the Presence API, so it would be more familiar to 
those who have used Presence API.
But if you have time, I would like some suggestions/opinions:

1) IMember -- currently represents both members and guests. Earlier I 
had a IMessageAuthor used instead of IMember at places, which was more 
general, and basically only provided a getName() method (and getUUID(), 
usage of which I replaced with calculating the UUID from the ID). The 
check whether an IMessageAuthor x was a guest was !(x instanceof 
IMember), but I didn't like this approach.

But currently it's not conceptually right -- a "guest" is now actually a 
"member" (with a different ID class, but that should be an internal 
impl. detail) and I made the "is this guy a guest" check nearly 
impossible -- must have forgotten that little detail while I was on the 
task :). So what I'm thinking now is:
a) make IMember extend IUser (from ECF Core)
b) replace usage of IMember in BBAPI with IUser as much as possible
c) use IMember only where group membership is concerned
d) IUser has a properties map -- maybe a property should tell whether a 
user is a guest or not?

Does this sound good? Looking at IUser usage, it currently seems to be 
used exclusively by UI bundles.

2) The Presence API prefers returning ID-s instead of full objects. For 
example, IIMMessage.getFromID() returns ID instead of some kind of User 
object. Bulletin Board API currently returns full objects in most cases. 
This originates from my own usage of the API -- it was/is mostly used in 
a way that usually expects to easily find the posters name and other 
details about a post. For example some Velocity templates could be 
written to directly reference a message author's name if given an 
IMessageBase object: ${message.from.name}.
However, if BBAPI usage is to increase, such optimizations may not fit 
all use cases and perhaps should be moved out of the API and left to the 
client code? What do you think? On the other hand, returning ID-s and 
expecting the full objects to be looked up separately if needed makes it 
less object oriented IMO.

3) Break some of the API-s into parts similar to the presence API's 
I*Manager -s. Not sure yet how exactly I would do this.

Erkki