[
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