[SNMP4J] API wish

[Mathias Bogaert]

Frank,

See inline.

Mathias

On 16 Mar 2005, at 23:15, Frank Fock wrote:

> Hi Mathias,
>
> These are my thoughts on your wishes:
>
> (1) Although java.sql is not my favorite Java API (I dislike the 
> one-based
> indexing of the ResultSet for example), making the access of response 
> values
> more convenient is a good point. As you indicate with your example,
> the access index for the values should be zero-based. In contrast to 
> your
> example, I would place the ResultSet like interface into the 
> ResponseEvent

I don't see what advantage putting it in ResponseEvent would have. I'm 
not sure if I still like the resultset idea, I'll think about it more.

> object. I wonder why you use Java native classes like Integer and Long?

If I would use primitives, how can I then differentiate between a 
returned zero value or NULL? With wrapper classes like Integer and Long 
this is possible. This way, also my data store can contain NULL.

> An OctetString would have to be returned as a byte Array then. The only
> advantage that I can see, is the independence from SNMP4J classes.
>
> (2) To make the implementation of the Target classes completly 
> "designed
> to interfaces", an Interface for UserTarget, SecureTarget, and
> CommunityTarget. Once these interfaces exists, one could also add a
> GenericTarget implementing both, IUserTarget and ICommunityTarget.

IUserTarget? I would'nt introduce C(++) type naming into the nicely 
designed SNMP4J. Just name it UserTarget and CommunityTarget

> I will add those for the 1.3 release if there is not anybody argueing 
> against
> it?
>
> (3) I would not call it peer address, because the already existing 
> getPeerAddress
> does not necessarily return the same address that was used as target 
> address when
> the request had been sent. I would name the method simply getTarge() 
> and that
> would then return the target instance that has been supplied with the 
> original request.
> Again, if there are no objections, I would add this to v1.3.

Excellent.

>
> Best regards,
> Frank
>
> Mathias Bogaert wrote:
>
>> Frank,
>>
>> Here a example how my ideal SNMP API would look.
>>
>>         snmp.send(pointerPDU, cableModem, new ResponseListener() {
>>             public void onResponse(ResponseEvent event) {
>>                 Integer macPointer = 
>> event.getResponse().getInteger(0);
>>                 if (macPointer != null) {
>>                     final PDU cpePdu = new PDU();
>>                     cpePdu.add(new VariableBinding(new 
>> OID(CPE_IP_ADDRESS + macPointer)));
>>                     snmp.send(cpePdu, event.getPeerTarget(), new 
>> ResponseListener() {
>>                         public void onResponse(ResponseEvent event) {
>>                             if (event.getResponse() != null) {
>>                                 // open database connection and dump 
>> data
>>                                 CableModemSample sample = new 
>> UnarchivedCableModemSample((CableModem) event.getPeerTarget());
>>                                 
>> sample.setDownstreamOctets(event.getResponse().getLong(0));
>>                                 
>> sample.setUpstreamOctets(event.getResponse().getLong(1));
>>                                 someDao.save(sample);
>>                             }
>>                             else {
>>                                 log.warn("time-out");
>>                             }
>>                         }
>>                     });
>>                 }
>>                 else {
>>                     log.warn("time-out");
>>                 }
>>             }
>>         });
>>
>> 1. notice the ResultSet like api for querying the returned values
>> 2. notice how the CableModem class implements TargetDetails and is 
>> directly usable as a target
>> 3. notice how the PeerTarget is passed to the second request
>>
>> Cheers,
>> Mathias Bogaert
>>
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>
>
>
>
>