[SNMP4J] API wish

[Frank Fock]

Mathias,

comments inline:

Mathias Bogaert wrote:

>
> 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.
>
It would keep the interface of PDU minimal. The ResultSet like interface 
will introduce
a couple of methods that I would rather put in external classes like 
ResponseEvent
than in a core class like PDU. BTW, putting it in the PDU class would 
then also require
set methods for symmetrical reasons.

>> 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.
>
Understood. I wondered why not using the SNMP4J types from the 
org.snmp4j.smi package?

>> 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 wouldn't have named them following the I convention. I was just an 
abbreviation.
However naming the interface like the current classes would break 
existing code,
which I want to avoid. May be someone has a good idea to fix this naming 
issue?

>> 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
>>>
>>
>>
>>
>>
>
>