[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Need advice for BBAPI refactoring

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