Contributions?

[Jay Lynch]

Hi again!
I finally made some headway with the issues I was having with Caps and
the web service, and as a result have managed to get at least the
basics of what I was looking for up and running.

So I now have an actual operating DataIM implementation (Based very
heavily on the existing IM event/transaction/class, admittedly) to
test which is pretty well fleshed out and should be largely ready to
use.

Any interest? And if so how would I go about preparing patches, etc,
any preferences? (Sorry if any of this should be obvious, though I've
been a bit of an open source zealot for a while now I'm a bit new to
actually contributing to anything so public)

Jay

[Shawn Carnell]

We are totally interested!  

Are you using Eclipse/FB3?  If so, do you want to just generate a patch file which we can apply on our end?

Shawn

[Jay Lynch]

Great! I'm on FB3 so there's a few other odds and ends I've been
messing around with that'll need to come out, but I'll clean it up and
give it a go, will post back once I've got it sorted.

[Jay Lynch]

OK, I've given it a go, looks like can't add attachments here, so I
put it online:
http://flaim.novartech.net/wimas3/DataIMs.patch

It'll send/receive DataIMs quite happily using the session.sendDataIM
command, and received event.

The only 'breaking' change will be that a capability field has been
added to the dataIM methods and pushed forward in the argument list.
It's a required field for sending them so they wouldn't've been doing
much without it anyway though, so it shouldn't be breaking much!

Then a SendDataIM transaction, and updates to the DataIM event, both
based on the regular IM versions, with some edits for the
"base64encoded" property. (Didn't mean to step on any toes but it's
off by default, as it wasn't able to be set anywhere and was rather
vague, feel free to change)

That should be the lot, other than a very minor change to the session
constructor (It will accept an optional array of capabilities now), as
it appears with the web service at the moment you need to set the
capabilities at first connect for them to function.

I just checked out a clean copy, merged in the changes needed for
DataIMs to work, and then generated a patch from the root directory of
that, hopefully it's what you were looking for, if not just let me
know.

[Osman Ullah]

Jay,

This all looks great! However, I have a couple suggestions:

I recommend we don't pass in capabilities as part of the constructor.
Instead, the client can set both assertCapabilities and
interestedCapabilities after creating the session. It looks like the
construct isn't dependant on the capabilities so this should work
fine.

Also, the url param for base64 encoding looks like it is
"dataIsBase64", not "base64Encoded". I'll change the url parameter,
but I'll keep the property name the same.

Does that sound ok to you?

Thanks,
Osman

[Osman Ullah]

Hey, take back the comment about base64. I was looking in the wrong
place. :) Would still like to hear your thoughts on the
assertCapabilities property.

Thanks,
Osman

[Jay Lynch]

Capabilities should work either way, I suppose, I had just lumped it
in there to make sure I remembered to set them, as at present they
absolutely must be set before first connecting, or there is no way to
change them. (See: http://dev.aol.com/node/1284)

It helps me remember that when the hinting for the constructor pops up
with it, but I am notoriously lazy like that. =)

Could just as easily have the arrays themselves public and set them
manually, I see no reason why not, design decision I'll leave to you
guys.

Speaking of which, what sort of level of functionality are you looking
at putting into the library and what would be considered client
implemented features?
I'm working on a few things now that the DataIMs are in place, some
are obviously going to be for my client specifically but some could go
either way, such as basic file transfers, where are you looking to
draw the line?

On May 13, 2:31 am, "Osman Ullah" <osman.ul...@gmail.com> wrote:
> Hey, take back the comment about base64. I was looking in the wrong
> place. :) Would still like to hear your thoughts on the
> assertCapabilities property.
>
> Thanks,
> Osman
>

> On Mon, May 12, 2008 at 2:19 PM, Osman Ullah <osman.ul...@gmail.com> wrote:
> > Jay,
>
> >  This all looks great! However, I have a couple suggestions:
>
> >  I recommend we don't pass in capabilities as part of the constructor.
> >  Instead, the client can set both assertCapabilities and
> >  interestedCapabilities after creating the session. It looks like the
> >  construct isn't dependant on the capabilities so this should work
> >  fine.
>
> >  Also, the url param for base64 encoding looks like it is
> >  "dataIsBase64", not "base64Encoded".  I'll change the url parameter,
> >  but I'll keep the property name the same.
>
> >  Does that sound ok to you?
>
> >  Thanks,
> >  Osman
>